Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

isaqb foundation level > cert learning > Flashcards

cert learning Flashcards

1
Q

LZ 1-1 Wieviele definitionen von Softwarearchitekturen gibt es?

A

Dutzende

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

LZ 1-1 Es gibt genau eine Definition von Software Architektur (Wahr/Falsch)

A

Falsch, es gibt mehrere

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

LZ 1-1 Was ist mit Bausteinen gemeint

A

Bausteine oder auch “Building Blocks” sind die fundamentalen Strukturen eines Softwaresystems

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

LZ 1-1 Welche Gemeinsamkeiten haben Architekturen? Nenne 7 Schlagworte

A

Bausteine, Komponenten, Schnittstellen, Beziehungen, Strukturen, Konzepte, Prinzipien

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

LZ 1-7 Projektziele vs. Architekturziele, was ist die Aufgabe eines Architekten

A

Möglichst große Schnittmenge finden

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

LZ 1-3 Welche Phasen der Softwareentwicklung begleitet Softwarearchitektur

A

Alle (Spezifikation => Implementierung => Validierung => Betrieb)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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, …)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Nenne Einflussfaktoren für Architekturentscheidungen

A
  • Projektziele, Unternehmensstrategie, Geschäftsmodell
  • Budget & Zeit
  • Verfügbarkeit und Qualifikation von Mitarbeitern
  • Gesetze
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Welche Methodiken einsetzen um Komplexität managen? Nenne zwei

A
  • Mit Strukturen und Konnzepten

- Iterativ vorgehenen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Entwurfsentscheidungen unterliegen diversen Einflussfaktoren (Wahr / Falsch)

A

Ja, z. B. Gesetze, Time und Budget, Know How der Mitarbeiter, Qualtitätsansprüche

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Was versteht man unter Stakeholdern

A

Alle die mit dem System irgendwie zu tun haben oder interesse daran haben

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Stakeholder haben immer die gleichen Interessen (Wahr/Falsch)

A

Falsch

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Welche Werkzeuge/Methodiken gibt es für die Erhebung von Stakeholder, nenne Zwei

A
  • Stakeholder Priorisierungsmatrix

- Stakeholder Tabelle

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

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?

A
  • Anforderungen die besondere Auswirkung auf die Architektur haben (ASR) identifizieren und bearbeiten

Architecturally Significant Requirements

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Was bedeutet ASR

A

Archtecturally Significant Requirements, Anforderungen die maßgeblich die Architektur beeinflussen (können).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

LZ 1-6 Nenne fünf Schritte die nötig sind um Anforderungen zu klären

A
  • Stakeholder identifizieren
  • Kontext / Scope abgrenzen
  • Funktionen, Prozesse, Abläufe ermitteln / verstehen
  • Qualitätsziele ermitteln und präzisieren
  • Randbedingungen ermitteln
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

LZ 1-6 Was sind Funktionale Anforderungen

A

Was soll das System/Produkt tun

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

LZ 1-6 Was sind Qualitätsanforderungen

A

Wie schnell, sicher, flexibel, …, soll das System sein

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

LZ 1-6 Was sind Randbedinungen

A

Constraints, Dinge die nicht geändert werden können (Technik, Team, Resourcen, bestehende Systeme)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

LZ 1-6 Was sind Nicht-Anforderungen

A

Was soll ganz bewusst NICHT gemacht werden, out of scope

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

LZ 3-5 Was ist Kontextabgrenzung

A

In Diagram, Top Level

  • Zeigt System von außen
  • Schnittstellen zu Nachbarn (Fremdsystemen)
  • Die wichtigsten Anwendungsfälle (fachlicher Kontext)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

LZ 3-5 Was ist zusätzlich zum Diagram Kontextabgrenzung erforderlich

A

Eine Tabelle mit zusätzlichen Details, welche die Bausteine beschreibt

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

LZ 3-5 Wird ein technischer Kontext für die Kontextabgrenzung immer benötigt?

A

Nein, nur bei Bedarf

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

LZ 3-5 Wofür kann das Diagram Kontextabgrenzung genutzt werden, nenne drei

A
  • Kommunikation auf Toplevel, Feedback einholen
  • Klärung fachlicher Konstellationen
  • Kennzeichnung von Risiken
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

LZ 3-5 Welche Notationen gibt es für Kontextabgrenzung

A
  • Einfache Boxen und Pfeile mit Tabelle
  • Komponenten mit Schnittstellenobjekten
  • Diagram mit Ball/Socket Schnittstellen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

LZ 3-5 Was ist im Diagram Kontextabgrenzung irrelevant

A

Nachbarn der Nachbarn

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

LZ 3-5 Was kann man tun wenn es besonders viele Nachbarn im Diagram Kontextabgrenzung gibt

A

Fachliche Cluster bilden

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

LZ 1-5 Themen Architekt Management? Nenne Fünf

A
  • Risikoüberwachung und Eskalation
  • Entscheidungskompetenzen
  • Auswahl und Beurteilung der techn. Fähigkeiten von Bewerbern und Mitarbeitern
  • Auswahl Tools und Technologien
  • Organisation Entwicklungsteam
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

LZ 1-5 Themen Architekt Auftraggeber? Nenne drei

A
  • Verbreitung und Akzeptanz der Systemvision
  • Einschränkungen und Vorhaben/Wünsche berücksichtigen
  • Feedback einholen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

LZ 1-5 Themen Architekt Entwickler? Nenne 6

A
  • Akzeptanz der Architektur sicherstellen
  • Training und Beratung
  • Moderation und Koordination an den Schnittstellen
  • Durchsetzen der Architekturvorgaben
  • Feedback einholen und einarbeiten
  • Entscheidungen herbeiführen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

LZ 1-5 Themen Architekt Betrieb? Nenne 5

A
  • Sicherstellen der Betriebbarkeit
  • Hardwareanforderungen
  • Festlegen des Personalbedarfs
  • Einschränkunen und Anforderungen festhalten und berücksichtigen
  • Anforderungen an SLA definieren
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

LZ 1-2 Wie fachliche Anforderungen festhalten

A
  • Kernaufgaben aufzeigen mit 2-3 einletenden Sätzen, Fachbegriffe ins Glossar
  • Strukturieren nach Funktionalität und Cluster bilden
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

LZ 1-2 Wie können komplexe fachliche Anforderungen besser greifbar gemacht werden um sie zu klären/erklären

A
  • Architekturrelevante Aufgaben anhand von konkreten Beispielen (fachliche Szenarien) festhalten
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

Was ist “Qualität” in Software? Q: Ist == Soll

A

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”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

Was ist ein Qualitätsmerkmal (Quallity attribute, bilities)

A

Eine Eigenschaft an eine Software die üblihcherweise von Stakeholdern nicht explizit genannt werden. Beinflussen Erstellung, Benutzung oder Weiterentwicklung

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

Nenne drei Qualitätsmerkmale

A
  • Performance
  • Benutzbarkeit / Usability
  • Ausfallsicherheit
  • Testbarkeit
  • Wartbarkeit
  • Erweiterbarkeit

Sind in ISO 25010 geregelt

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

Was ist eine Qualitätsanforderung

A

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”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q

Ein Architekt muss alle Qualitsmerkmale auswendig kennen

A

Nein, sie sind in ISO 25010 geregelt und das nimmt man einfach als Referenz

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

Was versteht man unter Qualitätsziel und welche wesentlichen Dinge sollte ein Architekt abfragen?

A

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

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

Was ist für ein gutes Qualitätsszenario ausschlaggebend

A

Sind Konkret in einen Kontext gesetzt, möglichst präzise sowie Mess- und Validierbar.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

Nenne drei Kategorien von Qualitätszenarien

A
  • Verwendungszenarien (Use Cases scenarios)
  • Änderungsszenarien (Growth scenarios)
  • Stressszenarien (Exploratory scenarios)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
54
Q

Es können stets alle geforderten Qualitäten im vollen Umfang erfüllt werden

A

Nein, es gibt konkurierende Qualitäten. Zum Beispiel Sicherheit und Benutzbarkeit, 3 factor auth ist nicht besonders Benutzbar…

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
55
Q

Wie mit Konflikten bei Qualitäten umgehen

A
  • Priorisierung (Alles ist ein Trade-off)

- Priorisierung erfolgt in der Regel anhand der Geschäftsziele

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
56
Q

Wie können Prioritäten für Qualitäten festgehalten werden? Nenne 2 Methodiken

A
  • In Tabelle aufgeschrieben und Prios vergeben

- In einem Qualitätsbaum mit Prioritäten

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
57
Q

Woher kommen initiale Qualitätsanforderungen in der Regel. Nenne drei

A
  • Geschäftsziele
  • Projektauftrag
  • Anforderungs-Workshop (z. B. Mini Quality Attribute Workshop, Quality Storming)
58
Q

Woher können kontinuierlich neue Qualitätsanforderungen kommen

A

Die Welt dreht sich weiter, es gibt neue Anforderungen, Scope hat sich geändert oder man ist einfach “schlauer Geworden “über die Zeit

59
Q

LZ 2-3 Was sind Randbedingungen / Constraints im Bezug auf Lösungen für Softwaresysteme?

A

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
Q

LZ 2-3 Können Randbedingungen für die Architekturarbeit auch Hilfreich sein?

A

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
Q

LZ 2-3 Nenne fünf typische Kategorien von Randbedingungen

A
  • Technische (z. B. Hardware)
  • Organisatorische (Personal, Budget, Termin)
  • Geltende Konventionen (Coding Guidelines)
  • Randbedingungen welche Systemgrenzen überschreiten (Compliance)
  • Gesetzgebung (z. B. Datenschutz)
62
Q

LZ 2-3 Welche Produktbezogenen Einflussfaktoren gibt es, nenne drei

A
  • Funktionale Anforderungen
  • Qualitsanfordeurngen und Qualitätsziele
  • Zusätzliches wie Kosten, Lizenz- oder Geschäftsmodell
63
Q

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)

A
  • Extern beauftragte technische Entscheidungen und Konzepte
  • bestehende Hardware Infrastruktur
  • Technologiebeschränkungen für Datenstrukturen und Schnittstellen
  • Referenzarchitekturen, Bibliotheken, Komponenten und Frameworks
64
Q

LZ 2-3 Nenne vier organisatorische Einflussfaktoren

A
  • Organisation Entwicklungsteam und Kunden
  • Normen und Richtlinien
  • Verfügbarkeit von Resourcen wie Budget Zeit und Perosonal
  • Verfügbarkeit Qualifikation und Engagement von MItarbeitern
65
Q

Vorgehesmuster in der Architekturarbeit nach “Architekturbrezel”. Am besten Aufmalen

A

Ein Kreislauf aus

Anforderung Priorisieren Analyse
Links von Analyse: Architektur, Reflexion
Rechts von Analyse: Umsetzung, Review

66
Q

LZ 3-2 Nenne drei Methodische Werkzeuge die bei der Architekturarbeit helfen können

A
  • Business Use Cases
  • Sceteches / Wireframes
  • Rapid Prototyping
  • Event Storming
67
Q

LZ 3-2 Welche Analogie passt zum Vorlagen-basiertem vorgehen (Templates)

A

Schrank, jeder Teil der Architektur hat sein Fach / Platz im Schrank

68
Q

LZ 3-2 Vorteile von vorlagen basiertem Vorgehen, nenne 5

A
  • 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
Q

LZ 2-6 Nenne Grundsätzliche Entwurfsprinzipien

A
  • KISS
  • YAGNI
  • Separation of Concerns (SoC)
  • Geheimnisprinzip
  • Lose Kopplung
  • Hohe Kohäsion
  • Konsistenz
  • Robustheitsprinzip
70
Q

LZ 2-6 Arten von Kopplung

A
  • Aufruf
  • Benachrichtigung
  • Erzeugung
  • Besitz

Weitere:

  • Vererbung
  • Datenstrukturen
  • Laufzeitumgebung
  • Zeit
71
Q

LZ 2-6 Was bedeutet Kohäsion im deutschen

A

Zusammenhangskraft, ein Maß für den inneren Zusammenhalt von Elementen (Bausteinen)

72
Q

LZ 2-6 Was bedeutet KISS und welche 5 Vorteile bringt es

A

Keep it simple and stupid

  • Einfacher implementierbar
  • Verständlicher
  • Wartbar
  • Kommunizierbar
  • Weniger Fehler
73
Q

LZ 2-6 Was bedeutet Separation of Concerns und was sollte mindestens beachtet werden

A

Aufteilung komplexer Systeme nach Verantwortlichkeit

Mindestens fachliche und technische Belange trennen

74
Q

LZ 2-6 Was sagt das Geheimnisprinzip aus (Information Hiding) und wie kann es erreicht werden

A

Schutz von Baustein internas gegen Zugriff von außen.

Nicht alles Public machen sondern definierte Schnittstellen für Bausteine verwenden

75
Q

LZ 2-6 Was bedeutet Bausteine sind Lose gekoppelt / haben eine lose Kopplung

A

Es gibt wenige Abhängikeiten zwischen den Bausteinen

76
Q

LZ 2-6 Warum ist Hohe Kopplung schlecht (im gegensatz zu Loser)

A
  • Geringe Wartbarkeit / Änderbarkeit

- Hohe Fehleranfälligkeit

77
Q

LZ 2-6 Was bedeutet Hohe Kohäsion (Zusammenhangskraft) für Bausteine

A
  • Erledigt inhaltlich zusammengehörige Aufgaben
78
Q

LZ 2-6 Was hat das Entwurfsprinzip “Konsistenz” (Mustertreue) zum Ziel?

A
  • Das Rad nicht immer neu erfinden
  • Konzeptionelle Integrität herstellen
    • Identische Probleme identisch lösen
    • Kognetive Last reduzieren
79
Q

LZ 2-6 Wie funktioniert das Robustheitsprinzip

A
  • Erwarte stets Fehler von anderen

- Selbst möglichst sauber bleiben

80
Q

LZ 2-6 Wo muss man vorsichtig sein wenn man beim Robustheitsprinzip Fehler von anderen erwartet

A
  • Keine Werte raten
81
Q

LZ 2-6 SOLID steht für

A

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
Q

LZ 2-1 Was ist Top-Down Design

A

Eine methodische Vorgehensweise bei der die Architektur vom groben ins Feine beschrieben wird

83
Q

LZ 2-1 Welche Vorteile hat ein Top-Down Design, nenne zwei

A
  • Überblick über Hauptkomponenten

- “Hohe Flugbahn”, daher geringes Risiko bei der Erstellung

84
Q

LZ 2-1 Welche Nachteile hat ein Top-Down Design, nenne drei

A
  • Verständnisfehler wirken sich auf nachfolgende Ergebnisse aus
  • (Test)-Ergebnisse liegen erst später vor
  • Details werden vernachlässigt
85
Q

LZ 2-1 Was ist Bottom-Up Design

A

Ein Methodik bei der vom feinen ins grobe designed wird

86
Q

LZ 2-1 Vorteile Bottom-Up Design

A
  • Schnelles erzielen von Ergebnissen

- Frühzeitiges Erkennen von Risiken

87
Q

LZ 2-1 Nachteile Bottom-Up Design

A
  • Teilergebnisse unter Umständen für weitere Schritte ungeeignet, da sie nicht ins Gesamtbild passen
88
Q

LZ 2-1 Können Top-Down und Bottom-Up zusammen verwendet werden?

A

Ja beide ergänzen sich gegenseitig

89
Q

LZ 2-2 Was ist eine Blackbox und wo findet sie Anwendung

A

In der Bausteinsicht werden einzelne Bausteine als Blackbox dargestellt. Das innere der Blackbox wird nicht betrachtet

90
Q

LZ 2-2 Was ist eine Whitebox

A

Eine Blackbox kann aufgeklappt werden zu einer Whitebox. In der Whitebox wird das innere Verhalten aufgezeigt. Bestimmte Teile werden wiederum als Blackbox betrachtet

91
Q

LZ 3-8 Wie funktioniert die fachliche Zerlegung um Bausteine zu ermitteln

A

Anhand von Fachlichkeiten werden Cluster/Gruppen gebildet die zusammen gehören bzw. ähnliche Aufgaben erledigen. Jedes Cluster bildet dann einen Baustein

92
Q

Was ist bei Qualitätszielen mit Wechselwirkung gemeint

A

Sie können gegenseitig im Konflikt stehen

93
Q

Wie geht man vor bei Quality driven Software Architektur

A
  • 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
Q

Wie können explizite Maßnahmen für Quality driven Software architecture festgehalten werden

A

In einer Tabelle mit den Priorisierten Qualitätszielen wird eine Spalte für Taktiken/Maßnahmen ergänzt

95
Q

LZ 2-4 Was ist ein Konzept allgemein im Kontext Querschnittkonzepte (cross cutting concerns)

A

Eine Taktik oder Maßnahme zur Lösung von immer wieder kehrenden Problemen die nicht spezifisch sind für ein Softwaresystem.

96
Q

LZ 2-4 Nenne drei Beispiele für Querschnittkonzepte

A
  • Logging
  • Autorisierung / Authentifizierung
  • Reporting
  • Batch
97
Q

LZ 2-4 Wie können Querschnittkonzepte oder Konzepte allgemein in einem diagram dargestellt werden

A
  • In dem man ein zusätzliches Tag an den Baustein schreibt, z.b Entity

Entity |
| Person. |
|————-|

98
Q

LZ 2-4 Was sind Stereotypen

A

Modellierungskonstrukt, um Semantik von Bausteinen/Schnittstellen/Beziehungen klarer zu definieren

Ein Tag zur Kategoriesierung, quasi

99
Q

LZ 2-4 Stereotypen können auch im Code bestimmte Namenskonventionen sein (Wahr/Falsch)

A

Wahr, zum Beispiel CustomerRepository pder Address*Repository

100
Q

LZ 2-4 Wie können Stereotypen dokumentiert werden und wo werden sie am besten abgelegt

A

Wie: Tabelle mit Beschreibung
Wo: Glossar

101
Q

Sind Konzepte wiederverwendbar für unterschiedliche Systeme?

A

Ja

102
Q

Was sind Architekturtaktiken?

A

Feingranulare Konzepte welche zur Erreichung von Qualitätszielen beitragen

103
Q

Nenne drei Beispiele für Architekturtaktiken

A

Ping / Echo
Heartbeat
Monitoring

104
Q

Architekturtaktiken lassen sich bestimmten Qualitätszielen zuordnen um diese zu erreichen

A

Ja, z. B. Ping / Echo für Störung erkennen

105
Q

LZ 3-8 Welche zwei Kategorien von Entwurfsentscheidungen gibt es

A

Irreversibel, kaum bis gar nicht änderbar

Reversibel, leicht änderbar

106
Q

LZ 3-8 Mit welchem methodischen Werkzeug können Entwurfsentscheidung festgehalten werden

A

Mit Architecture Decision Record (ADR)

107
Q

LZ 3-8 Welche Bestandteile hat ein Architecture Decision Record (ADR)

A

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
Q

LZ 2-5 Erkläre die Schichtenarchitektur (Layers)

A
  • 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
Q

LZ 2-5 Vorteile Schichtenarchitektur? Nenne 4

A
  • Abhängigkeiten sind klar organisiert
  • Reduktion der Abhängikeiten zwischen Komponenten
  • Platz für einheitlichen Abstraktionsgrad
  • Einfach und verständlich
110
Q

LZ 2-5 Nachteile Schichtenarchitektur

A
  • 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
Q

LZ 2-5 Beispiele für typische Schichten

A

GUI, Business Logik, Persistenz

112
Q

LZ 2-5 Wie funktioniert Pipes & Filters

A

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
Q

LZ 2-5 Herausforderungen bei Pipes & Filters, Nenne 4

A
  • Erkennung von Folgefehlern
  • Zentrale Steuerung vs Intelligenz in Pipes und Filter
  • Keine gemeinsamen Zustände
  • Komplexe Aufbauten schwer Testbar
114
Q

LZ 2-5 Definition von Microservices?

A

Nicht eindeutig definiert, nur

“Unabhängig deploybare Services”

115
Q

LZ 3-4 Welche vier wichtigen Sichten für Softwarearchitekturen gibt es

A

Kontextabgrenzung (Auch Kontextsicht)
Bausteinsicht
Laufzeitensicht
Verteilungssicht

116
Q

LZ 3-4 Wie funktioniert die Bausteinsicht

A
  • 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
Q

LZ 3-4 Was ist zusätzlich zu Erklärung der Bausteinsicht immer erforderlich

A

Eine Tabelle mit Auflistung der Bausteine und zusätzlicher Beschreibung

118
Q

LZ 3-7 Wie kommunizieren Bausteine

A

Bausteine kommunizieren über definierte Schnittstellen

119
Q

LZ 3-7 Kriterien einer guten Schnittstelle? Nenne 7

A
  • 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
Q

LZ 3-7 Aufgaben bei Schnittstellenentwurf

A
  • Formate bestimmen
  • Übertragungsweg (technisches Protokoll)
  • Ablauf
  • Fehlerbehandlung
  • Versionierung / Evolution
121
Q

LZ 3-7 Was ist für die Beschreibung von Schnittstellen erforderlich, nenne 6

A
  • Syntax (Daten, Resourcen)
  • Semantik (Nebenwirkungen, ausgelöste Ereignisse, geänderte Zustände)
  • Restriktionen (wer, wann)
  • Version + Gültigkeit
  • Fehlerbehandlung
  • Qulitätsmerkmale
122
Q

LZ 3-4 Was zeigt die Laufzeitsicht

A

Zeigt wie ein System eine bestimmte Aufgabe erfüllt

123
Q

LZ 3-4 Welche Notationen gibt es um eine Laufzeitsicht zu erstellen, nenne 3 (es gibt noch mehr)

A
  • Sequenzdiagram / Aktivitätsdiagram
  • Flussdiagram
  • Nummerierte Liste / Text
124
Q

LZ 3-4 Welche Szenarien sollten mit der Laufzeitsicht dargestellt werden

A

Nur die wichtigsten!

  • Wesentliche Anwendungsfälle
  • Kritische Situationen bei bekannten Problemen
  • Externe Schnittstellen
125
Q

LZ 3-4 Über was genau gibt eine Laufzeitensicht Aufschluss

A

Über

  • Datenfluss
  • Paralellisierung
  • Prozesse
  • Betriebszustände
126
Q

LZ 3-4 Nenne Ziele der Verteilungssicht

A
  • Zeigt Struktur / Aufbau der beteiligten Hardware

- Zeigt welche Software auf welcher Hardware läuft

127
Q

LZ 3-4 Nenne die wesentlichen drei Bestandteile einer Verteilungssicht

A
  • Knoten (Verarbeitungseinheiten)
  • Kanäle (Netze, Kommunikationskanäle)
  • Zuordnung (Welcher Software-Baustein auf welcher Hardware)
128
Q

LZ 3-4 Können Verteilungssichten genutzt werden um verschiedene Stages aufzuzeigen (DEV, QA, Prod) Wahr/Falsch

A

Wahr

Man macht einfach mehrere Verteilungssichten pro Stage

129
Q

LZ 3-4 Welchen Nutzen haben Sichten? Nenne zwei

A
  • Systeme aus unterschiedlichen Perspektiven zeigen

- Beziehungen zwischen Sichten aufzeigen

130
Q

LZ 3-3 UML-Diagramme für Kontextsicht?

A
  • Komponentendiagram

- Paketdiagram

131
Q

LZ 3-3 UML-Diagramme für Bausteinsicht?

A
  • Komponentendiagramm
  • Paketdiagram
  • Klassendiagram

(Wie UML für Kontextsicht plus Klassendiagram)

132
Q

LZ 3-3 UML-Diagramme für Verteilungssicht

A
  • Verteilungsdiagram
133
Q

LZ 3-3 UML-Diagramme für Laufzeitsicht

A
  • Sequenzdiagramm

- Aktivitätsdiagramm

134
Q

LZ 3-2 Dokumentation sollte bedarfsgerecht für Stakeholder und deren Informationsbedarf zugeschnitten sein (Wahr/Falsch)

A

Wahr

135
Q

LZ 3-3 Welche Anforderungen gibt es an technische Doku

A
  • Angemessenheit
  • Korrektheit
  • Wartbar
  • Verständlich
  • Inkrementell erstellt
136
Q

Wo hilft Architekturbewertung

A

Bewerten steuert alle Übriegen Aufgaben, nur wenn ich weiß das ich am Ziel vorbei bin kann ich auch etwas dagegen tun

137
Q

Welche zwei Arten von Architekturbewertungen gibt es

A
  • Quantitative Bewertung

- Qualitative Bewertung

138
Q

LZ 4-4 Wie geht Quantitative Bewertung

A

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
Q

LZ 4-4 Wobei helfen Metriken die durch Quantitative Bewertung erhoben wurden

A

Durch das Messen bestimmter Eigenschaften helfen Metriken bei der Beurteilung der inneren Qualität eines Systems

140
Q

LZ 4-3 Was macht man bei einer Qualitativen Bewertung von Softwarearchitektur

A

Man bewertet die Softwarequalität im Prinzip nach Soll-/Ist

Man nimmt zum Bepsiel das Quality-Attribut Web und vergleicht Soll gegen Ist

141
Q

Ein Konzept kann Einschränkungen für die Umsetzung vieler Bausteine definieren (Wahr/Falsch)

A

Wahr

isaqb foundation level (2 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions