Kapitel 1 Applikations-Architektur VI Software Architecture, Quality & Testing FS 2016 Prof. Dr. Jana Koehler jana.koehler@hslu.ch
Agenda Systemstruktur und Architekturentscheidungen müssen dokumentiert und kommuniziert werden. Was? Für wen? Warum? Wie? "If it is not written down, it does not exist." Philipp Kruchten 2
Sichten und Standpunkte (Views /Viewpoints) Eine Sicht stellt ein vollständiges System aus dem Blickwinkel einer Menge von zusammenhängenden Interessen heraus dar. [IEEE Standard 1471] Sicht als Menge von zusammengehörenden architekturrelevanten Elementen, die erstellt und genutzt wird von den Interessenvertretern eines Systems A viewpoint (Standpunkt) is a collection of patterns, templates and conventions for constructing one type of view. It defines the stakeholders, guidelines and principles and template models for constructing its views. 3
Warum Sichten? Moderne Software ist oft zu komplex, um sie als Gesamtheit anschauen und verstehen zu können Wir müssen unsere Aufmerksamkeit zu jedem Zeitpunkt auf einen (oder wenige) Teile der Systemstruktur lenken Um problemlos kommunizieren zu können, müssen wir klar machen, welche Strukturen (oder auch Verhalten) wir jetzt diskutieren SICHT als Darstellung der ausgewählten Strukturen Architekten entwerfen Strukturen und dokumentieren diese Strukturen durch Sichten 4
Erstellen guter Sichten Bedarfsgerecht Welche Information benötigt ein Interessenvertreter? So wenig Formalismus wie möglich, so viel wie nötig! Umfang der Sicht am Risiko orientiert Je mehr Risikofaktoren in einem Baustein, desto mehr Details in seiner Beschreibung Top-down arbeiten und Sichten weiter verfeinern 5
Wann ist eine Sicht gut? "gut für was"? - was wollen wir damit erreichen? Wenn sie die von uns intendierte Botschaft korrekt und mit Erfolg dem Empfänger überbringt und wir das Ziel unserer Botschaft erreichen 6
Sichten in der Gebäudearchitektur Grundriss Aufriss Elektriker Fliesenleger 7
Sichten in der Kommunikation des Architekten Anforderungen klären Entwerfen Starke: Effektive Software Architekturen Architektur bewerten Kommunizieren Entscheidungen motivieren Entwürfe propagieren Architektur dem Team vermitteln Unterschiedliche Sichten (Abstraktionen) für unterschiedliche Beteiligte 8
In der Version von Starke Vogel et al: Software Architektur 9
Das 4+1 Sichten Modell von Kruchten (+Sichten n. Starke) Kontext Sicht Baustein Sicht Laufzeit Sicht Verteilungs Sicht 10
4 Sichten nach Starke 11
Aufgabe K5: Kontextsicht für Kolumbus I. Entwickeln Sie die Kontextsicht für Ihr System. Sind alle Akteure und Benutzer vertreten? Sehen Sie alle Ihnen bekannten vorhandenen Systeme, mit denen das neue System interagieren wird? II. Annotieren Sie die Schnittstellen mit den allen Ereignissen und Informationen, die über die Systemgrenzen fliessen. 12
Aufgabe K6: Systemidee für Kolumbus AG verfeinern I. Schauen Sie Ihre Systemidee unter dem Gesichtspunkt der Architekturprinzipien an. Modularisieren Sie Ihre Systemidee. Bilden Sie Bausteine ihres Systems und ordnen Sie die Anforderungen den einzelnen Bausteinen zu. Berücksichtigen Sie auch das Prinzip der Rückverfolgbarkeit. II. Welche Verantwortlichkeiten werden von welchem Baustein übernommen? III. Wie steht es um Offenheit/Geschlossenheit sowie Erweiterbarkeit Ihrer Systemidee? Vgl. Phase 1 und Phase 2 des PIR Verkaufssystems 13
Aufgabe K7: Vertiefung Sichten I. Lesen Sie Kapitel 4 zu Sichten aus dem Buch von Starke. Entwerfen Sie 2 verschiedene erste Sichten für ihr PIR Verkaufssystem. Für welchen Stakeholder haben Sie Ihre Sicht entworfen? II. Überarbeiten (ggf. korrigieren) und verfeinern Sie ihren gewählten Architekturstil sowie die eingesetzten Integrationsmuster. 14
Kontextabgrenzung - Systemkontext Diagramm/Kontextsicht Wie ist das System in seine Umgebung eingebettet? Das System als Blackbox aus Vogelperspektive Schnittstellen zu allen(!) Nachbarsystemen Alle ein- und ausgehenden Daten und Ereignisse Interaktionen mit wichtigen Stakeholdern Wesentliche Teile der umgebenden Infrastruktur Oft auch Vision des zu bauenden Systems Oft abstrakter als die übrigen Sichten, aber 15
Bedeutung der Kontextsicht Als Überblicksdiagramm zum Umfeld des Systems Als die Sicht zur Ressourcenplanung und Risikomanagement Anzahl & Art der Schnittstellen nach aussen Anzahl & Art der Abhängigkeiten von Umsystemen Anzahl & Art der beteiligten Stakeholder Immer eine ganz detaillierte Sicht erstellen, wenn der Projektumfang verhandelt wird 16
Beispiel Kontextsicht - Was fehlt hier? Verkaufsvorhersagen ForeCasting Marketingleiter Kundenbetreuer Zu bauendes System Bestellsystem CRM Amadeus Reisekataloge 17
Was können Sie anhand dieser Kontextsicht über das System aussagen? Quelle: IBM 18
Erster Entwurf einer Kontextsicht 19
Verbesserung 20
Bausteinsicht Wie ist das System intern aufgebaut? Statische Strukturen der Architekturbausteine des Systems Subsysteme, Komponenten und deren Schnittstellen Top-Down Verfeinerungen Letzte (mögliche) Verfeinerungsstufe ist der Quellcode Projektleiter und Auftraggeber bei der Projektüberwachung unterstützen Zuteilung von Arbeitspaketen (Architekturbausteine) an Teams und Mitarbeiter Referenz für Software-Entwickler 21
Beispiele zu Bausteinsichten 22
23
24
25
26
Laufzeitsicht Wie läuft das System ab? Dynamische Strukturen und Abläufe im System Welche Bausteine des Systems existieren zur Laufzeit? Wie wirken sie zusammen? 27
Beispiel einer Laufzeitsicht als UML Aktivitätendiagramm 28
Beispiel einer Laufzeitsicht als UML Sequenzdiagramm 29
Verteilungssicht (Infrastruktursicht) In welcher Umgebung läuft das System ab? System aus Betreibersicht Verteilung des Systems auf die physischen Systeme Hardwarekomponenten, auf denen das System abläuft Rechner, Prozessoren, Netztopologien und -protokolle 30
Beispiel einer Verteilungssicht 31
Verteilungssicht Variante 1 32
Verteilungssicht Variante 2 33
34
35
36
Kontextsicht 37
Kontextsicht 38
39
40
41
42
43
44
45
46
Vorschlag Kontextsicht und Systemidee 47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
Aufgabe 2: Welcher Sicht würden Sie dieses Überblicksdiagramm zuordnen? 66
Aufgabe 3: Welcher Sicht würden Sie dieses Überblicksdiagramm zuordnen? 67
Weitere wichtige Sichten Für die Beurteilung der Qualitäten des Systems (und die Erfüllung der nichtfunktionalen Anforderungen) können ergänzende Sichten wichtige Informationen liefern: Security Sicht (aus unterschiedlichen Perspektiven) Information User Experience (GUI) Mehr zu Stakeholdern, ihren Standpunkten und Perspektiven und den möglichen Sichten 68
Die Dokumentation der Architektur 69
Work Products 70
Beispiel: Work Products des Treasury Enterprise Architecture Framework (TEAF) 71
Software Architektur Dokumentation Auch Architektur-Gesamtdokument, Architektur-Referenz oder Architecture-State-of-the-Art Enthält die verschiedensten work products, insbesondere Aufgabenstellung, Anforderungen und Ziele, Stakeholder Randbedingungen und Kontextsicht Weitere Sichten, Begriffsglossare Entwurfsentscheidungen und verwendete Muster Szenarien zur Architekturbewertung Risiken, change requests, Projektaspekte Keine wirklich gute Tool-Unterstützung zur Zeit verfügbar 72
Templates & Vorlagen Firmen & Organisationen definieren eigene Frameworks Vorgaben für einheitliche Terminologie, Rollen, Arbeitsphasen, Work products, Templates z.b. IBM Unified Method Framework (UMF), DoDAF, TOGAF Hruschka/Starke: http://arc42.de/ Standards ISO 10746 Referenzmodell für Open Distributed Processing http:// www.rm-odp.net IEEE 1471/ ISO 42010 Recommended Practice for Architectural Description of Software-intensive Systems http://www.iso-architecture.org/ieee-1471/ 73
Wie gelangt man zu einer guten Dokumentation? Klarheit schaffen und für einheitliches Verständnis unter Stakeholdern sorgen Begriffe definieren & konsistent verwenden Dokumentation strukturieren und Struktur kommunizieren Das Warum dokumentieren Entscheidungen, Alternativen, Ergebnis mit Begründung Redundanz vermeiden Konsistenz von Diagrammen und Sichten sichern 74
Fragen, die eine gute Dokumentation beantworten sollte Wie fügt sich das System in seine Umgebung ein, insbesondere in seine technische Infrastruktur? Wie ist das System als Menge von Implementierungseinheiten strukturiert und welche Beziehungen gibt es zwischen diesen? Wie verhalten sich die Bausteine zur Laufzeit und wie arbeiten sie zusammen? 75
Möglicher Aufbau einer guten Dokumentation Architektur-Überblick Dokumentations- Übersicht Übersichts- Präsentation Anforderungen und Lösungsansatz Systemkontext Glossar der wichtigsten Begriffe Sichten Umsetzung der nichtfunktionalen Anforderungen 76
Ebenen der Architektur Auf welchen Abstraktionsstufen bewegt sich ein Architekt im Rahmen seiner Tätigkeit? Auf welchen Ebenen trifft er Entscheidungen? Wie manifestiert sich Architektur auf diesen Abstraktionsstufen? "Mithilfe von Architektur-Ebenen ist man sich als Architekt den Kräften und ihren Ursprüngen bewusster, die auf eine Architektur grundsätzlich immer einwirken. Auf Bausteinebene wirken Kräfte von der Systemebene und auf Systemebene Kräfte von der Organisationsebene auf eine Architektur. Durch das Bewusstsein über diese Sachverhalte werden bei der Erstellung einer Architektur die auftretenden Problem- und Fragestellungen auf einheitlichere Weise behandelt und die Vermischung von unterschiedlichen Aspekten eher vermieden." 77
Ebenen Probleme den passenden Ebenen zuordnen und damit einfacher und einheitlicher handhaben Unterschiedliche Probleme trennen Einflüsse auf eine Architektur liegen explizit vor, können besser verstanden und berücksichtigt werden Vogel et al: Software Architektur 78
79
Architekturentscheidungen und Ebenen Ebenen (nach Zimmermann) Exekutiv Ebene Konzeptuelle Ebene Technologie Ebene Hersteller Ebene Grundlegende Entscheidung Architekturstil Architekturmuster Java EE oder.net? Oracle oder IBM? Microsoft? Entscheidungen sind nicht unabhängig voneinander! O. Zimmermann et al.: Managing architectural decision models with dependency relations, integrity constraints, and production rules. Journal of Systems and Software (2009) 80
Beispielabhängigkeiten zwischen Entscheidungen Presentation Layer Issues t 1 Web Page Flow i 1 a 11 MVC Pattern Figure Legend: (Outcomes not shown) topic group Conceptual Level (Platform-Independent) Business Logic Interface d a 21 d Bean View Concept a 32 Code issue i 2 a 22 Plain Object i 3 a 31 f Server Pages alternative contains Technology Level (Platform-Specific, here: Java) Java Presentation Layer Issues t 1 i 4 r a 41 i Java Server Pages (d)ecomposesinto (r)efinedby (f)orces Zimmermann, 2009 81 Java View Technology a 42 Java Servlets (in)compatiblewith
Dokumentation von Architektur Entscheidungen Problem, Alternativen, Ergebnis Ihrer Entscheidung Begründung!! ISO 42010 Review Draft 82
Ist das eine gute Dokumentation der Entscheidung? 83
Aufgabe K8: Architekturentscheidungen I. Dokumentieren Sie eine Ihrer wichtigsten Architekturentscheidungen durch Angabe von Problem (issue), Alternativen (alternatives), Getroffener Entscheidung (outcome), Begründung (rationale). 84
Zusammenfassung Nachlesen im Starke: Kapitel 4 und 5 im Kapitel 12 konkrete Beispiele für Sichten Güte von Sichten ist relativ Gute Sichten sind wichtig und erfolgsentscheidend Entscheidungen immer präzise dokumentieren Rückversicherung des Architekten für den Krisenfall 85
Arbeitsfragen 1. Womit dokumentieren Sie die Systemstrukturen? 2. Was verstehen wir unter einer Sicht und welche Sichten kennen Sie? 3. Welche Anforderungen erfüllen gute Sichten? 4. Was sollte in einer Architekturdokumentation enthalten sein? 5. Wie dokumentieren Sie Entscheidungen nach ISO 42010? 86