Vorlesung 5: Methoden für den Architekturentwurf (Fortgesetzt) Flashcards
Erkläre das Attribute-Driven Design (attributgesteuerte Design)
▪ Attributgesteuertes Design (ADD) ist eine iterative Methode
zum Entwurf von Software-Architekturen
▪ ADD kann bereits verwendet werden, wenn nur eine Menge von ASRs
bereits bekannt ist
▪ Zusätzlich zu den ASRs ist der Kontext eines Systems ein
wichtiger Input
- Grenzen des zu entwerfenden Systems
- Externe Systeme / Benutzer, mit denen das System interagiert
▪ Das Ergebnis der ADD ist eine Reihe von “Entwürfen” von Architektursichten
- Sammlung von Architekturelementen
- Interaktion dieser Elemente
▪ Konstruierte Architektursichten bilden die Grundlage für
zukünftige Arbeit
▪ Die Beendigung kann auf der Grundlage des erforderlichen Wissensstandes variieren
Erkläre die Schritte 1 bis 5 des Attributgesteuerten Design: Verfahren
Schritt 1.:Wähle ein Systemelement zum Entwerfen:
In der ersten Iteration wird wahrscheinlich das Gesamtsystem entworfen, um relevante architektonische Elemente zu identifizieren (besonders bei Greenfield-Projekten).
In den nächsten Iterationen wird eines dieser Elemente ausgewählt.
Zwei Strategien zur Auswahl von Elementen: Zuerst die Breite (bevorzugt) oder zuerst die Tiefe (z.B. um Risiken zu mindern oder um Verfügbarkeitsbeschränkungen von Personen zu berücksichtigen).
Schritt 2.:Identifiziere die architektonisch signifikanten Anforderungen (ASRs):
Beginne mit dem bestehenden Qualitätbaum.
Spezifische Qualitätsbäume für bestimmte architektonische Elemente zu konstruieren, kann hilfreich sein.
Schritt 3.:Generiere eine Designlösung:
Entwickle die Lösung basierend auf den ASRs.
Verwende die Strategie “Generate-and-Test”.
Die Lösung wird durch bekannte architektonische Taktiken/Muster/Stile beeinflusst (das Rad nicht neu erfinden!), muss jedoch spezifischer sein.
Entscheidungen, die in diesem Schritt getroffen werden, stellen Einschränkungen für zukünftige Iterationen dar.
Neue architektonische Elemente können identifiziert werden, die in zukünftigen Iterationen verfeinert werden.
Schritt 4.:Verifiziere und verfeinere Anforderungen:
Verifiziere alle relevanten ASRs für dieses Element.
Wenn einige ASRs letztendlich nicht erfüllt werden können, muss das Design überdacht werden.
ASRs, Einschränkungen und funktionale Anforderungen der übergeordneten Elemente können berücksichtigt werden.
Schritt 5: Wiederhole Schritt 1 bis 4.
Sieh dir die Abbildung an: Attribute-Driven Design: Refinement Example (Beispiel für Verfeinerung)
Bitte gehe auf die Bedeutung von Architekturentscheidungen ein
Entscheidungen in der Softwarearchitektur
Die Softwarearchitektur resultiert aus getroffenen Entscheidungen; ADD (Attribute-Driven Design) basiert auf dem Treffen und Dokumentieren dieser Entscheidungen.
Entscheidungen zu treffen ist die wichtigste Aufgabe eines Softwarearchitekten; es ist eine Kunst, architektonische Entscheidungen zu fällen.
Keine Entscheidungen zu treffen ist schlimmer als „schlechte“ Entscheidungen zu treffen.
Wichtig zu beachten:
Alles in der Softwarearchitektur ist ein Kompromiss!
Das „Warum“ ist wichtiger als das „Wie“!
Architektonisch signifikante Entscheidungen betreffen:
Strukturen
Qualitätsanforderungen
Abhängigkeiten und Schnittstellen
Konstruktionsmethoden (einschließlich Plattformen, Frameworks, Werkzeuge etc.)
Bereiche von Architekturentscheidungen:
Zuweisung von Verantwortlichkeiten: „Welcher Teil des Systems ist für was verantwortlich?“
Koordinationsmodell: „Wie kommunizieren die Teile des Systems und wie wird die Kommunikation koordiniert?“
Datenmodell: „Wie werden Daten im System verwaltet und organisiert?“
Ressourcenmanagement: „Welche harten und weichen Ressourcen (z.B. Sperren) benötigt das System?“
Zuordnung zwischen architektonischen Elementen: „Wie werden konzeptionelle Elemente der Architektur auf das System abgebildet?“
Bindungszeitpunkt: „Was kann zur Laufzeit geändert werden?“
Technologieauswahl: „Welche Technologien werden für welche Teile verwendet?“
Anti-Patterns von Architekturentscheidungen:
-Covering your ass-Pattern:
Problem: Entscheidungen werden aus Angst vor falschen Entscheidungen vermieden.
Vermeiden von Analyseparalyse; Entscheidungen bis zum letztmöglichen Moment aufschieben.
Zusammenarbeit mit Entwicklern, um Daten zu sammeln und getroffene Entscheidungen anzupassen.
-Groundhog day-Pattern:
Problem: Begründungen für Entscheidungen werden nicht dokumentiert, und Diskussionen beginnen immer wieder von neuem.
Technische und geschäftliche Begründungen für Architekturentscheidungen müssen dokumentiert werden.
-Email-driven architecture-Pattern:
Problem: Entscheidungen werden nicht richtig dokumentiert und kommuniziert (z.B. in einer Vielzahl von E-Mails, an die sich niemand erinnert).
Eine zentrale Datenbank für Architekturentscheidungsprotokolle sollte implementiert werden.
Entscheidungsträger müssen über getroffene Entscheidungen informiert werden.
Was sind Architektur-Entscheidungssätze (Architecture Decision Records: ADRs)
Dokumentation von Architekturentscheidungen
Effektive Methode der Dokumentation: Verwendung strukturierter Entscheidungsprotokolle (ADRs) in einem einheitlichen Raum.
Vorgeschlagen von: Michael Nygard (2011).
Grundstruktur von ADRs:
Titel: Kurze Beschreibung der Entscheidung (ein paar Worte).
Status: Ist diese Entscheidung bereits getroffen? Oder noch nicht begonnen?
Kontext: Was macht diese Entscheidung relevant? Was sind die Rahmenbedingungen?
Optionen: Während der Entscheidungsfindung können mehrere Optionen entdeckt werden, die dokumentiert werden sollten.
Entscheidung: Dokumentation der getroffenen Entscheidung und deren Begründung (einschließlich Diskussion der Optionen).
Konsequenzen: Positive und negative Auswirkungen der Entscheidung (alles ist ein Kompromiss…).
Einhaltung: Wie kann die Entscheidung durchgesetzt / die Einhaltung sichergestellt werden?
Notizen: Autoren, Stakeholder, zusätzliche Metadaten.
Speicherort für ADRs:
Neben dem Quellcode des betreffenden Systems oder in einem anderen Versionskontrollsystem (VCS).
In einem Wiki-ähnlichen System (empfohlen).
Teamarbeit: Erstellen, Diskutieren und Überprüfen von ADRs sollte im Team erfolgen.
Tipps zur Verwendung von ADRs:
Nur architektonisch relevante Entscheidungen dokumentieren.
Entscheidungskriterien dokumentieren.
Gründe für wichtige Entscheidungen angeben.
Abgelehnte Alternativen dokumentieren.
ADRs spezifisch halten.
Immer Zeitstempel einfügen.
Entschiedene ADRs unveränderlich lassen (nachträglich keine zusätzlichen Informationen hinzufügen).
