Kapitel 1 Applikations-Architektur VI

Transkript

1 Kapitel 1 Applikations-Architektur VI Software Architecture, Quality & Testing FS 2016 Prof. Dr. Jana Koehler jana.koehler@hslu.ch

2 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

3 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

4 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

5 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

6 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

7 Sichten in der Gebäudearchitektur Grundriss Aufriss Elektriker Fliesenleger 7

8 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

9 In der Version von Starke Vogel et al: Software Architektur 9

10 Das 4+1 Sichten Modell von Kruchten (+Sichten n. Starke) Kontext Sicht Baustein Sicht Laufzeit Sicht Verteilungs Sicht 10

11 4 Sichten nach Starke 11

12 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

13 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

14 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

15 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

16 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

17 Beispiel Kontextsicht - Was fehlt hier? Verkaufsvorhersagen ForeCasting Marketingleiter Kundenbetreuer Zu bauendes System Bestellsystem CRM Amadeus Reisekataloge 17

18 Was können Sie anhand dieser Kontextsicht über das System aussagen? Quelle: IBM 18

19 Erster Entwurf einer Kontextsicht 19

20 Verbesserung 20

21 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

22 Beispiele zu Bausteinsichten 22

23 23

24 24

25 25

26 26

27 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

28 Beispiel einer Laufzeitsicht als UML Aktivitätendiagramm 28

29 Beispiel einer Laufzeitsicht als UML Sequenzdiagramm 29

30 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

31 Beispiel einer Verteilungssicht 31

32 Verteilungssicht Variante 1 32

33 Verteilungssicht Variante 2 33

34 34

35 35

36 36

37 Kontextsicht 37

38 Kontextsicht 38

39 39

40 40

41 41

42 42

43 43

44 44

45 45

46 46

47 Vorschlag Kontextsicht und Systemidee 47

48 48

49 49

50 50

51 51

52 52

53 53

54 54

55 55

56 56

57 57

58 58

59 59

60 60

61 61

62 62

63 63

64 64

65 65

66 Aufgabe 2: Welcher Sicht würden Sie dieses Überblicksdiagramm zuordnen? 66

67 Aufgabe 3: Welcher Sicht würden Sie dieses Überblicksdiagramm zuordnen? 67

68 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

69 Die Dokumentation der Architektur 69

70 Work Products 70

71 Beispiel: Work Products des Treasury Enterprise Architecture Framework (TEAF) 71

72 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

73 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: Standards ISO Referenzmodell für Open Distributed Processing IEEE 1471/ ISO Recommended Practice for Architectural Description of Software-intensive Systems 73

74 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

75 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

76 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

77 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

78 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 79

80 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

81 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, Java View Technology a 42 Java Servlets (in)compatiblewith

82 Dokumentation von Architektur Entscheidungen Problem, Alternativen, Ergebnis Ihrer Entscheidung Begründung!! ISO Review Draft 82

83 Ist das eine gute Dokumentation der Entscheidung? 83

84 Aufgabe K8: Architekturentscheidungen I. Dokumentieren Sie eine Ihrer wichtigsten Architekturentscheidungen durch Angabe von Problem (issue), Alternativen (alternatives), Getroffener Entscheidung (outcome), Begründung (rationale). 84

85 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

86 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