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