1
Q
LZ 1-1 Wieviele definitionen von Softwarearchitekturen gibt es?
A
Dutzende
2
Q
LZ 1-1 Es gibt genau eine Definition von Software Architektur (Wahr/Falsch)
A
Falsch, es gibt mehrere
3
Q
LZ 1-1 Was ist in ISO 42010 geregelt
A
Formelle Beschreibung von Software Architektur
Die grundsätzliche Organisation eines Systems, wie sie sich in dessen Komponenten, deren Beziehung zueinander und zur Umgebung widerspiegelt, sowie die Prinzipien die für seinen Entwurf und seine Evolution gelten.
4
Q
LZ 1-1 Was ist mit Bausteinen gemeint
A
Bausteine oder auch “Building Blocks” sind die fundamentalen Strukturen eines Softwaresystems
5
Q
LZ 1-1 Welche statischen Strukturen(Sichten) gibt es
A
Bausteinsicht (Bausteine und Beziehungen), Verteilungssicht (Systeme und deren Umgebung, auf welchen Servern laufen sie und welche Hardware ist beteiligt)
6
Q
LZ 1-1 Welche Gemeinsamkeiten haben Architekturen? Nenne 7 Schlagworte
A
Bausteine, Komponenten, Schnittstellen, Beziehungen, Strukturen, Konzepte, Prinzipien
7
Q
LZ 1-1 Nenne fünf Gemeinsamkeiten vieler Architekturdefinitionen
A
- Strukturelemente (Allgemein Bausteine oder konkrete Komponenten) und deren Zerlegung
- Beziehungen zwischen den Elementen und ihrer Umgebung
- Grundsätze, die Design und Enwicklung des Systems bestimmten
- Entwurfsentscheidungen,
- Unterstützt Evolution eines Systems
8
Q
LZ 1-2 Formuliere einen Satz zum Ziel von Softwarearchitektur
A
Softwarearchitektur hat zum Ziel Softwaresysteme längerfristig in angemessener Zeit, Qualität und Kosten weiterentwickeln zu können
9
Q
LZ 1-7 Architekturziele und Projektziele sind immer gleich (wahr/falsch)
A
Falsch, sind oft Konträr. Projektziele sind eher kurzfristig und Architekturziele eher langfristig, daher müssen möglichst große Schnittmengen gefunden werden
10
Q
LZ 1-7 Projektziele vs. Architekturziele, was ist die Aufgabe eines Architekten
A
Möglichst große Schnittmenge finden
11
Q
LZ 1-3 Welche Phasen der Softwareentwicklung begleitet Softwarearchitektur
A
Alle (Spezifikation => Implementierung => Validierung => Betrieb)
12
Q
LZ 1-6 Welche Aufgaben gehören zu der Rolle Softwarearchitekt
A
- Anforderungen und Randbedingungen klären
- Strukturen entwerfen
- Querschnittkonzepte einbringen
- Architektur kommunizieren
- Umsetzung begleiten
- Architektur bewerten
13
Q
LZ 1-5 Nenne zwei Möglichkeiten wie die Rolle “Softwarearchitekt” sinnvoll in Teams eingesetzt werden kann
A
- Aufgabenverteilung mit Architekturagenten; Hierbei werden Architekturthemen explizit verteilt sodass Entwickler ihr eigenes Teilgebiet haben
- Dedizierter Architekt im Entwicklungsteam, unterstützt Team bei Architekturaufgaben / entwickelt mit / leitet an
14
Q
LZ 1-8 Warum Architekturziele explizit aufschreiben
A
- Sichert Konsitenz bei Entscheidungen
- Fördert abstimmen und festlegen mit relevanten Stakehholdern
- Legt auch Abwägungen (Tradeoffs) offen
15
Q
LZ 1-8 Warum sind implizite Aussagen schlecht
A
Aussagen die implizit getroffen werden (u. a. Wünsche) oder Annahmen die “einfach so” getroffen werden, werden vergessen wenn es darauf ankommt. Daher lieber explizit aufschreiben
16
Q
LZ 1-2 Warum Langfristigkeit, geht Software kaputt?
A
Software geht nicht von alleine kaputt, aber Welt dreht sich weiter. Ständiges Anpassen und iteratives vorgehen Notwendig
17
Q
LZ 1-2 Welchen Nutzen hat Softwarearchitektur, wie Unterstützt sie in der Organisation
A
- Bindeglied zwischen Analyse (Business) und Umsetzung (Technik)
- Unterstützt Entwicklung Initial und kontinuierlich (Neuentwicklung, Weiterentwicklung, Wartung, …)
18
Q
Nenne Einflussfaktoren für Architekturentscheidungen
A
- Projektziele, Unternehmensstrategie, Geschäftsmodell
- Budget & Zeit
- Verfügbarkeit und Qualifikation von Mitarbeitern
- Gesetze
19
Q
LZ 1-10 Durch den Typ eines Systems werden meist die Kernaufgaben bekannt. Nenne sechs Typen
A
- Interaktives Online System (CRUD Business Anwendung)
- Mobile Systeme
- Entscheidungsunterstützung (datawarehouse, dashboards)
- Hintergrundsysteme (Batch Systeme, Nachtjobs für Datenmanipulation)
- Eingebettete Systeme (Firmware)
- Echtzeitsysteme, Operationen werden in garantierter Zeit erledigt
20
Q
Welche Methodiken einsetzen um Komplexität managen? Nenne zwei
A
- Mit Strukturen und Konnzepten
- Iterativ vorgehenen
21
Q
Entwurfsentscheidungen unterliegen diversen Einflussfaktoren (Wahr / Falsch)
A
Ja, z. B. Gesetze, Time und Budget, Know How der Mitarbeiter, Qualtitätsansprüche
22
Q
Was versteht man unter Stakeholdern
A
Alle die mit dem System irgendwie zu tun haben oder interesse daran haben
23
Q
Wichtige Fragen bei der Stakeholderanalyse
A
- Wer nimmt Einfluss und wer ist betroffen?
- Was ist die Erwartungshaltung?
- Wie Stark/mächtig ist der Einfluss und Worauf
- Wo gibt es Konflikte
24
Q
Stakeholder haben immer die gleichen Interessen (Wahr/Falsch)
A
Falsch
25
Welche Werkzeuge/Methodiken gibt es für die Erhebung von Stakeholder, nenne Zwei
- Stakeholder Priorisierungsmatrix
| - Stakeholder Tabelle
26
LZ 1-6 Bei der Stakeholder Analyse werden auch die Anforderungen die oft nur schwammig vorliegen geklärt. Worauf müssen Software Architekten besonders achten?
- Anforderungen die besondere Auswirkung auf die Architektur haben (ASR) identifizieren und bearbeiten
Architecturally Significant Requirements
27
Was bedeutet ASR
Archtecturally Significant Requirements, Anforderungen die maßgeblich die Architektur beeinflussen (können).
28
LZ 1-6 Nenne fünf Schritte die nötig sind um Anforderungen zu klären
- Stakeholder identifizieren
- Kontext / Scope abgrenzen
- Funktionen, Prozesse, Abläufe ermitteln / verstehen
- Qualitätsziele ermitteln und präzisieren
- Randbedingungen ermitteln
29
LZ 1-6 Was sind Funktionale Anforderungen
Was soll das System/Produkt tun
30
LZ 1-6 Was sind Qualitätsanforderungen
Wie schnell, sicher, flexibel, ..., soll das System sein
31
LZ 1-6 Was sind Randbedinungen
Constraints, Dinge die nicht geändert werden können (Technik, Team, Resourcen, bestehende Systeme)
32
LZ 1-6 Was sind Nicht-Anforderungen
Was soll ganz bewusst NICHT gemacht werden, out of scope
33
LZ 3-5 Was ist Kontextabgrenzung
In Diagram, Top Level
- Zeigt System von außen
- Schnittstellen zu Nachbarn (Fremdsystemen)
- Die wichtigsten Anwendungsfälle (fachlicher Kontext)
34
LZ 3-5 Was ist zusätzlich zum Diagram Kontextabgrenzung erforderlich
Eine Tabelle mit zusätzlichen Details, welche die Bausteine beschreibt
35
LZ 3-5 Wird ein technischer Kontext für die Kontextabgrenzung immer benötigt?
Nein, nur bei Bedarf
36
LZ 3-5 Wofür kann das Diagram Kontextabgrenzung genutzt werden, nenne drei
- Kommunikation auf Toplevel, Feedback einholen
- Klärung fachlicher Konstellationen
- Kennzeichnung von Risiken
37
LZ 3-5 Welche Notationen gibt es für Kontextabgrenzung
- Einfache Boxen und Pfeile mit Tabelle
- Komponenten mit Schnittstellenobjekten
- Diagram mit Ball/Socket Schnittstellen
38
LZ 3-5 Was ist im Diagram Kontextabgrenzung irrelevant
Nachbarn der Nachbarn
39
LZ 3-5 Was kann man tun wenn es besonders viele Nachbarn im Diagram Kontextabgrenzung gibt
Fachliche Cluster bilden
40
LZ 1-5 Themen Architekt Management? Nenne Fünf
- Risikoüberwachung und Eskalation
- Entscheidungskompetenzen
- Auswahl und Beurteilung der techn. Fähigkeiten von Bewerbern und Mitarbeitern
- Auswahl Tools und Technologien
- Organisation Entwicklungsteam
41
LZ 1-5 Themen Architekt Auftraggeber? Nenne drei
- Verbreitung und Akzeptanz der Systemvision
- Einschränkungen und Vorhaben/Wünsche berücksichtigen
- Feedback einholen
42
LZ 1-5 Themen Architekt Entwickler? Nenne 6
- Akzeptanz der Architektur sicherstellen
- Training und Beratung
- Moderation und Koordination an den Schnittstellen
- Durchsetzen der Architekturvorgaben
- Feedback einholen und einarbeiten
- Entscheidungen herbeiführen
43
LZ 1-5 Themen Architekt Betrieb? Nenne 5
- Sicherstellen der Betriebbarkeit
- Hardwareanforderungen
- Festlegen des Personalbedarfs
- Einschränkunen und Anforderungen festhalten und berücksichtigen
- Anforderungen an SLA definieren
44
LZ 1-2 Wie fachliche Anforderungen festhalten
- Kernaufgaben aufzeigen mit 2-3 einletenden Sätzen, Fachbegriffe ins Glossar
- Strukturieren nach Funktionalität und Cluster bilden
45
LZ 1-2 Wie können komplexe fachliche Anforderungen besser greifbar gemacht werden um sie zu klären/erklären
- Architekturrelevante Aufgaben anhand von konkreten Beispielen (fachliche Szenarien) festhalten
46
Was ist "Qualität" in Software? Q: Ist == Soll
Das was die Software in Gänze machen soll und wie sie das geforderte erfüllt.
"Softwarequalität ist die Gesamtheit der Merkmalen und Merkmalswerte eines Softwareproduktes die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen"
47
Was ist ein Qualitätsmerkmal (Quallity attribute, bilities)
Eine Eigenschaft an eine Software die üblihcherweise von Stakeholdern nicht explizit genannt werden. Beinflussen Erstellung, Benutzung oder Weiterentwicklung
48
Nenne drei Qualitätsmerkmale
- Performance
- Benutzbarkeit / Usability
- Ausfallsicherheit
- Testbarkeit
- Wartbarkeit
- Erweiterbarkeit
Sind in ISO 25010 geregelt
49
Was ist eine Qualitätsanforderung
Eine konkrete Ausprägung von einem Qualitätsmerkmal
Mit Hilfe von Qualitätszenarien werden Qualitätsmerkmale zu konkreten Qualitätsanforderungen die ein Softwaresystem erfüllen muss
Beispiel: "Von 1000 Benutzern können 90% den Businessprozess X alleine durchführen, ohne den Hilfe Button zu verwenden"
50
Ein Architekt muss alle Qualitsmerkmale auswendig kennen
Nein, sie sind in ISO 25010 geregelt und das nimmt man einfach als Referenz
51
Was versteht man unter Qualitätsziel und welche wesentlichen Dinge sollte ein Architekt abfragen?
Auch Architekturziel genannt, am Anfang von einem Projekt sollten 5 bis 10 der wesentlichen Qualitätsanforderungen der maßgeblichen Stakeholder erfasst werden. Diese Anforderungen sind priorisiert.
Hier müssen vom Architekten wesentliche Dinge abgefragt werden welche die Architektur maßgeblich beinflussen können (Performance, Sicherheit, Änderbarkeit, Bedienbarkeit, ...) Hierzu gehören auch Mengengerüste
52
Was ist für ein gutes Qualitätsszenario ausschlaggebend
Sind Konkret in einen Kontext gesetzt, möglichst präzise sowie Mess- und Validierbar.
53
Nenne drei Kategorien von Qualitätszenarien
- Verwendungszenarien (Use Cases scenarios)
- Änderungsszenarien (Growth scenarios)
- Stressszenarien (Exploratory scenarios)
54
Es können stets alle geforderten Qualitäten im vollen Umfang erfüllt werden
Nein, es gibt konkurierende Qualitäten. Zum Beispiel Sicherheit und Benutzbarkeit, 3 factor auth ist nicht besonders Benutzbar...
55
Wie mit Konflikten bei Qualitäten umgehen
- Priorisierung (Alles ist ein Trade-off)
| - Priorisierung erfolgt in der Regel anhand der Geschäftsziele
56
Wie können Prioritäten für Qualitäten festgehalten werden? Nenne 2 Methodiken
- In Tabelle aufgeschrieben und Prios vergeben
| - In einem Qualitätsbaum mit Prioritäten
57
Woher kommen initiale Qualitätsanforderungen in der Regel. Nenne drei
- Geschäftsziele
- Projektauftrag
- Anforderungs-Workshop (z. B. Mini Quality Attribute Workshop, Quality Storming)
58
Woher können kontinuierlich neue Qualitätsanforderungen kommen
Die Welt dreht sich weiter, es gibt neue Anforderungen, Scope hat sich geändert oder man ist einfach "schlauer Geworden "über die Zeit
59
LZ 2-3 Was sind Randbedingungen / Constraints im Bezug auf Lösungen für Softwaresysteme?
Dinge die wir nicht beeinflussen können und aus Gründen einfach so sind wie sie sind
"Wie das Wetter, kann man nicht ändern aber man kann sich darauf einstellen"
60
LZ 2-3 Können Randbedingungen für die Architekturarbeit auch Hilfreich sein?
Ja, sie können zum Teil schwierige Entscheidungen abnehmen. Zum Beispiel wenn C# gesetzt ist brauch man sich über die Wahl der Programmiersprache nicht mehr den Kopf zerbrechen
61
LZ 2-3 Nenne fünf typische Kategorien von Randbedingungen
- Technische (z. B. Hardware)
- Organisatorische (Personal, Budget, Termin)
- Geltende Konventionen (Coding Guidelines)
- Randbedingungen welche Systemgrenzen überschreiten (Compliance)
- Gesetzgebung (z. B. Datenschutz)
62
LZ 2-3 Welche Produktbezogenen Einflussfaktoren gibt es, nenne drei
- Funktionale Anforderungen
- Qualitsanfordeurngen und Qualitätsziele
- Zusätzliches wie Kosten, Lizenz- oder Geschäftsmodell
63
LZ 2-3 Welche technischen Einflussfaktoren gibt es, nenne vier (Es sind nicht Randbedinungen gemeint, sondern alles das, was Einfluss darauf nimmt wie man entscheidet)
- Extern beauftragte technische Entscheidungen und Konzepte
- bestehende Hardware Infrastruktur
- Technologiebeschränkungen für Datenstrukturen und Schnittstellen
- Referenzarchitekturen, Bibliotheken, Komponenten und Frameworks
64
LZ 2-3 Nenne vier organisatorische Einflussfaktoren
- Organisation Entwicklungsteam und Kunden
- Normen und Richtlinien
- Verfügbarkeit von Resourcen wie Budget Zeit und Perosonal
- Verfügbarkeit Qualifikation und Engagement von MItarbeitern
65
Vorgehesmuster in der Architekturarbeit nach "Architekturbrezel". Am besten Aufmalen
Ein Kreislauf aus
Anforderung Priorisieren Analyse
Links von Analyse: Architektur, Reflexion
Rechts von Analyse: Umsetzung, Review
66
LZ 3-2 Nenne drei Methodische Werkzeuge die bei der Architekturarbeit helfen können
- Business Use Cases
- Sceteches / Wireframes
- Rapid Prototyping
- Event Storming
67
LZ 3-2 Welche Analogie passt zum Vorlagen-basiertem vorgehen (Templates)
Schrank, jeder Teil der Architektur hat sein Fach / Platz im Schrank
68
LZ 3-2 Vorteile von vorlagen basiertem Vorgehen, nenne 5
- Hohe Verständlichkeit
- Wiederverwendbar
- Vereinfacht Know-How Transfer
- Verhindert bestimmte Dinge zu vergessen
- Dinge werden schneller gefunden da Strukturiert
- Da man weiß was wo hin gehört, höhere Read/Write Performance
69
LZ 2-6 Nenne Grundsätzliche Entwurfsprinzipien
- KISS
- YAGNI
- Separation of Concerns (SoC)
- Geheimnisprinzip
- Lose Kopplung
- Hohe Kohäsion
- Konsistenz
- Robustheitsprinzip
70
LZ 2-6 Arten von Kopplung
- Aufruf
- Benachrichtigung
- Erzeugung
- Besitz
Weitere:
- Vererbung
- Datenstrukturen
- Laufzeitumgebung
- Zeit
71
LZ 2-6 Was bedeutet Kohäsion im deutschen
Zusammenhangskraft, ein Maß für den inneren Zusammenhalt von Elementen (Bausteinen)
72
LZ 2-6 Was bedeutet KISS und welche 5 Vorteile bringt es
Keep it simple and stupid
- Einfacher implementierbar
- Verständlicher
- Wartbar
- Kommunizierbar
- Weniger Fehler
73
LZ 2-6 Was bedeutet Separation of Concerns und was sollte mindestens beachtet werden
Aufteilung komplexer Systeme nach Verantwortlichkeit
Mindestens fachliche und technische Belange trennen
74
LZ 2-6 Was sagt das Geheimnisprinzip aus (Information Hiding) und wie kann es erreicht werden
Schutz von Baustein internas gegen Zugriff von außen.
Nicht alles Public machen sondern definierte Schnittstellen für Bausteine verwenden
75
LZ 2-6 Was bedeutet Bausteine sind Lose gekoppelt / haben eine lose Kopplung
Es gibt wenige Abhängikeiten zwischen den Bausteinen
76
LZ 2-6 Warum ist Hohe Kopplung schlecht (im gegensatz zu Loser)
- Geringe Wartbarkeit / Änderbarkeit
| - Hohe Fehleranfälligkeit
77
LZ 2-6 Was bedeutet Hohe Kohäsion (Zusammenhangskraft) für Bausteine
- Erledigt inhaltlich zusammengehörige Aufgaben
78
LZ 2-6 Was hat das Entwurfsprinzip "Konsistenz" (Mustertreue) zum Ziel?
- Das Rad nicht immer neu erfinden
- Konzeptionelle Integrität herstellen
- - Identische Probleme identisch lösen
- - Kognetive Last reduzieren
79
LZ 2-6 Wie funktioniert das Robustheitsprinzip
- Erwarte stets Fehler von anderen
| - Selbst möglichst sauber bleiben
80
LZ 2-6 Wo muss man vorsichtig sein wenn man beim Robustheitsprinzip Fehler von anderen erwartet
- Keine Werte raten
81
LZ 2-6 SOLID steht für
Single responsibility, ein Klasse/Baustein soll nur eine Verantwortung haben und nur ein Grund sich zu ändern
Open Closed, Offen für Erweiterungen, aber geschlossen für Modifikationen
Liskov Substition Principle, Abgeleitete Klassen müssen die kontrakte ihrer Basis erfüllen
Interface Segration Principle, viele spezifische Schnittellen sind besser als eine große universelle
Dependency Inversion Principle, Abhängig sein gegenüber Abstraktionen; Nicht gegen Konkretes
82
LZ 2-1 Was ist Top-Down Design
Eine methodische Vorgehensweise bei der die Architektur vom groben ins Feine beschrieben wird
83
LZ 2-1 Welche Vorteile hat ein Top-Down Design, nenne zwei
- Überblick über Hauptkomponenten
| - "Hohe Flugbahn", daher geringes Risiko bei der Erstellung
84
LZ 2-1 Welche Nachteile hat ein Top-Down Design, nenne drei
- Verständnisfehler wirken sich auf nachfolgende Ergebnisse aus
- (Test)-Ergebnisse liegen erst später vor
- Details werden vernachlässigt
85
LZ 2-1 Was ist Bottom-Up Design
Ein Methodik bei der vom feinen ins grobe designed wird
86
LZ 2-1 Vorteile Bottom-Up Design
- Schnelles erzielen von Ergebnissen
| - Frühzeitiges Erkennen von Risiken
87
LZ 2-1 Nachteile Bottom-Up Design
- Teilergebnisse unter Umständen für weitere Schritte ungeeignet, da sie nicht ins Gesamtbild passen
88
LZ 2-1 Können Top-Down und Bottom-Up zusammen verwendet werden?
Ja beide ergänzen sich gegenseitig
89
LZ 2-2 Was ist eine Blackbox und wo findet sie Anwendung
In der Bausteinsicht werden einzelne Bausteine als Blackbox dargestellt. Das innere der Blackbox wird nicht betrachtet
90
LZ 2-2 Was ist eine Whitebox
Eine Blackbox kann aufgeklappt werden zu einer Whitebox. In der Whitebox wird das innere Verhalten aufgezeigt. Bestimmte Teile werden wiederum als Blackbox betrachtet
91
LZ 3-8 Wie funktioniert die fachliche Zerlegung um Bausteine zu ermitteln
Anhand von Fachlichkeiten werden Cluster/Gruppen gebildet die zusammen gehören bzw. ähnliche Aufgaben erledigen. Jedes Cluster bildet dann einen Baustein
92
Was ist bei Qualitätszielen mit Wechselwirkung gemeint
Sie können gegenseitig im Konflikt stehen
93
Wie geht man vor bei Quality driven Software Architektur
- Qualitätsziele erarbeiten welche Architektur maßgeblich beeinflussen
- Qualitätsziele möglichst konkret entscheidbar oder messbar
- Entwickle Maßnahmen zur Erreichung der Qualitätsziele
94
Wie können explizite Maßnahmen für Quality driven Software architecture festgehalten werden
In einer Tabelle mit den Priorisierten Qualitätszielen wird eine Spalte für Taktiken/Maßnahmen ergänzt
95
LZ 2-4 Was ist ein Konzept allgemein im Kontext Querschnittkonzepte (cross cutting concerns)
Eine Taktik oder Maßnahme zur Lösung von immer wieder kehrenden Problemen die nicht spezifisch sind für ein Softwaresystem.
96
LZ 2-4 Nenne drei Beispiele für Querschnittkonzepte
- Logging
- Autorisierung / Authentifizierung
- Reporting
- Batch
97
LZ 2-4 Wie können Querschnittkonzepte oder Konzepte allgemein in einem diagram dargestellt werden
- In dem man ein zusätzliches Tag an den Baustein schreibt, z.b _Entity_
-------------
| _Entity_ |
| Person. |
|-------------|
98
LZ 2-4 Was sind Stereotypen
Modellierungskonstrukt, um Semantik von Bausteinen/Schnittstellen/Beziehungen klarer zu definieren
Ein Tag zur Kategoriesierung, quasi
99
LZ 2-4 Stereotypen können auch im Code bestimmte Namenskonventionen sein (Wahr/Falsch)
Wahr, zum Beispiel Customer*Repository* pder Address*Repository
100
LZ 2-4 Wie können Stereotypen dokumentiert werden und wo werden sie am besten abgelegt
Wie: Tabelle mit Beschreibung
Wo: Glossar
101
Sind Konzepte wiederverwendbar für unterschiedliche Systeme?
Ja
102
Was sind Architekturtaktiken?
Feingranulare Konzepte welche zur Erreichung von Qualitätszielen beitragen
103
Nenne drei Beispiele für Architekturtaktiken
Ping / Echo
Heartbeat
Monitoring
104
Architekturtaktiken lassen sich bestimmten Qualitätszielen zuordnen um diese zu erreichen
Ja, z. B. Ping / Echo für Störung erkennen
105
LZ 3-8 Welche zwei Kategorien von Entwurfsentscheidungen gibt es
Irreversibel, kaum bis gar nicht änderbar
| Reversibel, leicht änderbar
106
LZ 3-8 Mit welchem methodischen Werkzeug können Entwurfsentscheidung festgehalten werden
Mit Architecture Decision Record (ADR)
107
LZ 3-8 Welche Bestandteile hat ein Architecture Decision Record (ADR)
Titel: Um welche Entscheidung geht es
Kontext: Was sind die Rahmenbedinungen
Entscheidung: Was war die Entscheindung, was die alternativen
Status: Wie steht es um das ADR, auch abgelehnt oder überholte aufführen
Konsequenzen: Mit welchen Vor- und Nachteilen wollen wir jetzt leben
TKESK
TKESK
TKESK
108
LZ 2-5 Erkläre die Schichtenarchitektur (Layers)
- Einzelne Schichten kapseln Details
- Schichten werden gestapelt (Reihenfolge)
- Untere Schicht stellt Dienste für darüberliegende Schicht bereit
- Eine Schicht hat niemals Abhängikeiten zu über ihr liegenden Schicht
109
LZ 2-5 Vorteile Schichtenarchitektur? Nenne 4
- Abhängigkeiten sind klar organisiert
- Reduktion der Abhängikeiten zwischen Komponenten
- Platz für einheitlichen Abstraktionsgrad
- Einfach und verständlich
110
LZ 2-5 Nachteile Schichtenarchitektur
- Evt Reduzierte performance weil durch N Schichten durchgereicht wird
- Erhöhte Komplexität für Simple Tasks (Neues Feld in UI, DB Erweiteurng und alles dazwischen)
- Änderungen können viele Schichten betreffen
- Gefahr von zuvielen oder zuwenigen Schichten
111
LZ 2-5 Beispiele für typische Schichten
GUI, Business Logik, Persistenz
112
LZ 2-5 Wie funktioniert Pipes & Filters
Ein Input geht in eine Pipe, Filter1 bearbeitet Input und gibt das Ergennis weiter an die Pipe und an den nächsten Filter2
Beispiel: ls | grep "c" | sort
113
LZ 2-5 Herausforderungen bei Pipes & Filters, Nenne 4
- Erkennung von Folgefehlern
- Zentrale Steuerung vs Intelligenz in Pipes und Filter
- Keine gemeinsamen Zustände
- Komplexe Aufbauten schwer Testbar
114
LZ 2-5 Definition von Microservices?
Nicht eindeutig definiert, nur
"Unabhängig deploybare Services"
115
LZ 3-4 Welche vier wichtigen Sichten für Softwarearchitekturen gibt es
Kontextabgrenzung (Auch Kontextsicht)
Bausteinsicht
Laufzeitensicht
Verteilungssicht
116
LZ 3-4 Wie funktioniert die Bausteinsicht
- Hierarchisch (Top-Down) aufgebaut (Level 1 zeigt weniger Details als Level 2)
- Zeigt Aufteilung des Systems in Bausteine und Abhängigkeiten zwischen diesen
- Verwendet Blackbox und Whitebox als Abstraktionen
117
LZ 3-4 Was ist zusätzlich zu Erklärung der Bausteinsicht immer erforderlich
Eine Tabelle mit Auflistung der Bausteine und zusätzlicher Beschreibung
118
LZ 3-7 Wie kommunizieren Bausteine
Bausteine kommunizieren über definierte Schnittstellen
119
LZ 3-7 Kriterien einer guten Schnittstelle? Nenne 7
- Angemessen für Benutzer
- Client Code leicht zu verstehen
- Neue Versionen brechen keinen bestehenden Code
- Einfach zu erlernen / benutzen / erweitern
- Schwer zu missbrauchen (forgiving)
- Vollständig aus Benutzersicht (Deckt alle Use-Cases ab)
- Erfüllt Qualitätsanforderungen
ACNE Sport Verein Ekelig
120
LZ 3-7 Aufgaben bei Schnittstellenentwurf
- Formate bestimmen
- Übertragungsweg (technisches Protokoll)
- Ablauf
- Fehlerbehandlung
- Versionierung / Evolution
121
LZ 3-7 Was ist für die Beschreibung von Schnittstellen erforderlich, nenne 6
- Syntax (Daten, Resourcen)
- Semantik (Nebenwirkungen, ausgelöste Ereignisse, geänderte Zustände)
- Restriktionen (wer, wann)
- Version + Gültigkeit
- Fehlerbehandlung
- Qulitätsmerkmale
122
LZ 3-4 Was zeigt die Laufzeitsicht
Zeigt wie ein System eine bestimmte Aufgabe erfüllt
123
LZ 3-4 Welche Notationen gibt es um eine Laufzeitsicht zu erstellen, nenne 3 (es gibt noch mehr)
- Sequenzdiagram / Aktivitätsdiagram
- Flussdiagram
- Nummerierte Liste / Text
124
LZ 3-4 Welche Szenarien sollten mit der Laufzeitsicht dargestellt werden
Nur die wichtigsten!
- Wesentliche Anwendungsfälle
- Kritische Situationen bei bekannten Problemen
- Externe Schnittstellen
125
LZ 3-4 Über was genau gibt eine Laufzeitensicht Aufschluss
Über
- Datenfluss
- Paralellisierung
- Prozesse
- Betriebszustände
126
LZ 3-4 Nenne Ziele der Verteilungssicht
- Zeigt Struktur / Aufbau der beteiligten Hardware
| - Zeigt welche Software auf welcher Hardware läuft
127
LZ 3-4 Nenne die wesentlichen drei Bestandteile einer Verteilungssicht
- Knoten (Verarbeitungseinheiten)
- Kanäle (Netze, Kommunikationskanäle)
- Zuordnung (Welcher Software-Baustein auf welcher Hardware)
128
LZ 3-4 Können Verteilungssichten genutzt werden um verschiedene Stages aufzuzeigen (DEV, QA, Prod) Wahr/Falsch
Wahr
Man macht einfach mehrere Verteilungssichten pro Stage
129
LZ 3-4 Welchen Nutzen haben Sichten? Nenne zwei
- Systeme aus unterschiedlichen Perspektiven zeigen
| - Beziehungen zwischen Sichten aufzeigen
130
LZ 3-3 UML-Diagramme für Kontextsicht?
- Komponentendiagram
| - Paketdiagram
131
LZ 3-3 UML-Diagramme für Bausteinsicht?
- Komponentendiagramm
- Paketdiagram
- Klassendiagram
(Wie UML für Kontextsicht plus Klassendiagram)
132
LZ 3-3 UML-Diagramme für Verteilungssicht
- Verteilungsdiagram
133
LZ 3-3 UML-Diagramme für Laufzeitsicht
- Sequenzdiagramm
| - Aktivitätsdiagramm
134
LZ 3-2 Dokumentation sollte bedarfsgerecht für Stakeholder und deren Informationsbedarf zugeschnitten sein (Wahr/Falsch)
Wahr
135
LZ 3-3 Welche Anforderungen gibt es an technische Doku
- Angemessenheit
- Korrektheit
- Wartbar
- Verständlich
- Inkrementell erstellt
136
Wo hilft Architekturbewertung
Bewerten steuert alle Übriegen Aufgaben, nur wenn ich weiß das ich am Ziel vorbei bin kann ich auch etwas dagegen tun
137
Welche zwei Arten von Architekturbewertungen gibt es
- Quantitative Bewertung
| - Qualitative Bewertung
138
LZ 4-4 Wie geht Quantitative Bewertung
Erhebung von bekannten Metriken wie Loc, zyklomatische Komplexität, Abhängigkeiten, Testabdeckung, etc ...
Diese werden über einen bestimmten Zeitraum (Tage/Wochen/Monate) erhoben und gemessen.
139
LZ 4-4 Wobei helfen Metriken die durch Quantitative Bewertung erhoben wurden
Durch das Messen bestimmter Eigenschaften helfen Metriken bei der Beurteilung der inneren Qualität eines Systems
140
LZ 4-3 Was macht man bei einer Qualitativen Bewertung von Softwarearchitektur
Man bewertet die Softwarequalität im Prinzip nach Soll-/Ist
Man nimmt zum Bepsiel das Quality-Attribut Web und vergleicht Soll gegen Ist
141
Ein Konzept kann Einschränkungen für die Umsetzung vieler Bausteine definieren (Wahr/Falsch)
Wahr
isaqb foundation level
flashcards
Decks in class (2)
# Cards
