Seminar: Software-ArchitekturEinführender Vortrag
Kay Schützler
Langjährige Annahme:
„Systeme werden auf der Grundlage technischer Anforderungen entwickelt“
Anforderungen Entwurf
Anforderungen Entwurf
Software-Architektur als Teil des Entwurfs-Prozesses
Beschreibung der Struktur großer Software-Systeme
Abstrakte Sicht mit Verzicht auf Implementations-, Algorithmen- und Datenrepräsentationsdetails
Konzentration auf das Verhalten und die Interaktion von „Black-Box“-Elementen
Erster Entwurfsschritt in Richtung eines Systems mit den gewünschten Eigenschaften
Anforderungen bekannt System erfolgreich erstellt?
Kurzsichtige Einschätzung– Beispiel: Das Kriegsschiff Vasa
http://www.vasamuseet.se/indexeng.html
Zwei unabhängige Architekten, ein Problem, eine Architektur?– Eher zwei Architekturen!
Die entscheidende Frage:
Welcher Zusammenhang besteht zwischen derSoftware-Architektur eines Systems und der Umgebung in der es entwickelt werden und
existieren soll?
Wo kommen Architekturen her?
Beeinflussung von Architekturen durch– „System-Interessentengruppe“
Kunde, Endnutzer, Entwickler, Projekt-Manager, Wartungsverantwortliche, Marketing-Abteilung, ...
– die entwickelnde Organisation– den Hintergrund und die Erfahrung der Architekten– die technische Umgebung
Einflüsse auf die Architektur
Architecture Business Cycle
Software-Architektur: Resultat technischer (funktionaler), betriebswirtschaftlicher und sozialer Einflüsse
Umgekehrt auch Beeinflussung des technischen, betriebswirtschaftlichen und sozialen Umfelds durch die Software-Architektur
„Architecture Business Cycle“
Architecture Business Cycle
Software-Prozesse und der Architecture Business Cycle
Aktivitäten bei der Erstellung einer Software-Architektur– Geschäftsfall erstellen– Anforderungen verstehen– Architektur auswählen/erstellen– Architektur analysieren/evaluieren– Architektur dokumentieren/veröffentlichen– System auf Architektur basierend implementieren– Übereinstimmung von Architektur und System
sicherstellen
Faustregeln für gute Architekturen: Prozessempfehlungen (1)
Architektur nur als Produkt eines einzelnen Architekten/eines kleinen Teams mit einem definiertem Entscheidungsträger
Vorhandensein von funktionalen Anforderungen und Qualitäts-Attributs-Liste mit Prioritäten
Gute Dokumentation der Architektur in gemeinsam akzeptierter Notation (mindestens eine statische und eine dynamische Sicht)
Faustregeln für gute Architekturen: Prozessempfehlungen (2)
Aktive Reviews der Architektur durch alle Interessenshalter des Projekts
Rechtzeitige Analyse der Architektur mit geeigneten Metriken und formale Evaluation bezüglich der Qualitäts-Attribute
Architektur mit Möglichkeit zur inkrementellen Implementation („Skelettsystem“, Prototyping)
Faustregeln für gute Architekturen: Strukturempfehlungen
Wohldefinierte Module unter Beachtung der Prinzipien des „Information Hiding“ und der „Separation of Concerns“
Wohldefinierte, unabhängigkeitsfördende Modul-Schnittstellen mit Kapselung veränderlicher Aspekte
Architektur niemals von einer bestimmten Version eines kommerziellen Produkts/Tools abhängig machen
And now to something completely different...
Verteilung der Vortragsthemen