Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Paulina Schräder Geändert vor über 9 Jahren
1
Seminar: Software-Architektur Einführender Vortrag
Kay Schützler
2
Langjährige Annahme: „Systeme werden auf der Grundlage technischer Anforderungen entwickelt“ Anforderungen Entwurf Anforderungen Entwurf
3
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
4
Anforderungen bekannt System erfolgreich erstellt?
Kurzsichtige Einschätzung Beispiel: Das Kriegsschiff Vasa Zwei unabhängige Architekten, ein Problem, eine Architektur? Eher zwei Architekturen!
5
Die entscheidende Frage:
Welcher Zusammenhang besteht zwischen der Software-Architektur eines Systems und der Umgebung in der es entwickelt werden und existieren soll?
6
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
8
Einflüsse auf die Architektur
9
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“
10
Architecture Business Cycle
11
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
12
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)
13
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)
14
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
15
And now to something completely different...
Verteilung der Vortragsthemen
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.