cert learning Flashcards
LZ 1-1 Wieviele definitionen von Softwarearchitekturen gibt es?
Dutzende
LZ 1-1 Es gibt genau eine Definition von Software Architektur (Wahr/Falsch)
Falsch, es gibt mehrere
LZ 1-1 Was ist in ISO 42010 geregelt
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.
LZ 1-1 Was ist mit Bausteinen gemeint
Bausteine oder auch “Building Blocks” sind die fundamentalen Strukturen eines Softwaresystems
LZ 1-1 Welche statischen Strukturen(Sichten) gibt es
Bausteinsicht (Bausteine und Beziehungen), Verteilungssicht (Systeme und deren Umgebung, auf welchen Servern laufen sie und welche Hardware ist beteiligt)
LZ 1-1 Welche Gemeinsamkeiten haben Architekturen? Nenne 7 Schlagworte
Bausteine, Komponenten, Schnittstellen, Beziehungen, Strukturen, Konzepte, Prinzipien
LZ 1-1 Nenne fünf Gemeinsamkeiten vieler Architekturdefinitionen
- 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
LZ 1-2 Formuliere einen Satz zum Ziel von Softwarearchitektur
Softwarearchitektur hat zum Ziel Softwaresysteme längerfristig in angemessener Zeit, Qualität und Kosten weiterentwickeln zu können
LZ 1-7 Architekturziele und Projektziele sind immer gleich (wahr/falsch)
Falsch, sind oft Konträr. Projektziele sind eher kurzfristig und Architekturziele eher langfristig, daher müssen möglichst große Schnittmengen gefunden werden
LZ 1-7 Projektziele vs. Architekturziele, was ist die Aufgabe eines Architekten
Möglichst große Schnittmenge finden
LZ 1-3 Welche Phasen der Softwareentwicklung begleitet Softwarearchitektur
Alle (Spezifikation => Implementierung => Validierung => Betrieb)
LZ 1-6 Welche Aufgaben gehören zu der Rolle Softwarearchitekt
- Anforderungen und Randbedingungen klären
- Strukturen entwerfen
- Querschnittkonzepte einbringen
- Architektur kommunizieren
- Umsetzung begleiten
- Architektur bewerten
LZ 1-5 Nenne zwei Möglichkeiten wie die Rolle “Softwarearchitekt” sinnvoll in Teams eingesetzt werden kann
- 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
LZ 1-8 Warum Architekturziele explizit aufschreiben
- Sichert Konsitenz bei Entscheidungen
- Fördert abstimmen und festlegen mit relevanten Stakehholdern
- Legt auch Abwägungen (Tradeoffs) offen
LZ 1-8 Warum sind implizite Aussagen schlecht
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
LZ 1-2 Warum Langfristigkeit, geht Software kaputt?
Software geht nicht von alleine kaputt, aber Welt dreht sich weiter. Ständiges Anpassen und iteratives vorgehen Notwendig
LZ 1-2 Welchen Nutzen hat Softwarearchitektur, wie Unterstützt sie in der Organisation
- Bindeglied zwischen Analyse (Business) und Umsetzung (Technik)
- Unterstützt Entwicklung Initial und kontinuierlich (Neuentwicklung, Weiterentwicklung, Wartung, …)
Nenne Einflussfaktoren für Architekturentscheidungen
- Projektziele, Unternehmensstrategie, Geschäftsmodell
- Budget & Zeit
- Verfügbarkeit und Qualifikation von Mitarbeitern
- Gesetze
LZ 1-10 Durch den Typ eines Systems werden meist die Kernaufgaben bekannt. Nenne sechs Typen
- 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
Welche Methodiken einsetzen um Komplexität managen? Nenne zwei
- Mit Strukturen und Konnzepten
- Iterativ vorgehenen
Entwurfsentscheidungen unterliegen diversen Einflussfaktoren (Wahr / Falsch)
Ja, z. B. Gesetze, Time und Budget, Know How der Mitarbeiter, Qualtitätsansprüche
Was versteht man unter Stakeholdern
Alle die mit dem System irgendwie zu tun haben oder interesse daran haben
Wichtige Fragen bei der Stakeholderanalyse
- Wer nimmt Einfluss und wer ist betroffen?
- Was ist die Erwartungshaltung?
- Wie Stark/mächtig ist der Einfluss und Worauf
- Wo gibt es Konflikte
Stakeholder haben immer die gleichen Interessen (Wahr/Falsch)
Falsch
Welche Werkzeuge/Methodiken gibt es für die Erhebung von Stakeholder, nenne Zwei
- Stakeholder Priorisierungsmatrix
- Stakeholder Tabelle
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
Was bedeutet ASR
Archtecturally Significant Requirements, Anforderungen die maßgeblich die Architektur beeinflussen (können).
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
LZ 1-6 Was sind Funktionale Anforderungen
Was soll das System/Produkt tun
LZ 1-6 Was sind Qualitätsanforderungen
Wie schnell, sicher, flexibel, …, soll das System sein
LZ 1-6 Was sind Randbedinungen
Constraints, Dinge die nicht geändert werden können (Technik, Team, Resourcen, bestehende Systeme)
LZ 1-6 Was sind Nicht-Anforderungen
Was soll ganz bewusst NICHT gemacht werden, out of scope
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)
LZ 3-5 Was ist zusätzlich zum Diagram Kontextabgrenzung erforderlich
Eine Tabelle mit zusätzlichen Details, welche die Bausteine beschreibt
LZ 3-5 Wird ein technischer Kontext für die Kontextabgrenzung immer benötigt?
Nein, nur bei Bedarf
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
LZ 3-5 Welche Notationen gibt es für Kontextabgrenzung
- Einfache Boxen und Pfeile mit Tabelle
- Komponenten mit Schnittstellenobjekten
- Diagram mit Ball/Socket Schnittstellen
LZ 3-5 Was ist im Diagram Kontextabgrenzung irrelevant
Nachbarn der Nachbarn
LZ 3-5 Was kann man tun wenn es besonders viele Nachbarn im Diagram Kontextabgrenzung gibt
Fachliche Cluster bilden
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
LZ 1-5 Themen Architekt Auftraggeber? Nenne drei
- Verbreitung und Akzeptanz der Systemvision
- Einschränkungen und Vorhaben/Wünsche berücksichtigen
- Feedback einholen
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
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
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
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
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”
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
Nenne drei Qualitätsmerkmale
- Performance
- Benutzbarkeit / Usability
- Ausfallsicherheit
- Testbarkeit
- Wartbarkeit
- Erweiterbarkeit
Sind in ISO 25010 geregelt
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”
Ein Architekt muss alle Qualitsmerkmale auswendig kennen
Nein, sie sind in ISO 25010 geregelt und das nimmt man einfach als Referenz
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
Was ist für ein gutes Qualitätsszenario ausschlaggebend
Sind Konkret in einen Kontext gesetzt, möglichst präzise sowie Mess- und Validierbar.
Nenne drei Kategorien von Qualitätszenarien
- Verwendungszenarien (Use Cases scenarios)
- Änderungsszenarien (Growth scenarios)
- Stressszenarien (Exploratory scenarios)
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…
Wie mit Konflikten bei Qualitäten umgehen
- Priorisierung (Alles ist ein Trade-off)
- Priorisierung erfolgt in der Regel anhand der Geschäftsziele
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
Woher kommen initiale Qualitätsanforderungen in der Regel. Nenne drei
- Geschäftsziele
- Projektauftrag
- Anforderungs-Workshop (z. B. Mini Quality Attribute Workshop, Quality Storming)
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
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”
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
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)
LZ 2-3 Welche Produktbezogenen Einflussfaktoren gibt es, nenne drei
- Funktionale Anforderungen
- Qualitsanfordeurngen und Qualitätsziele
- Zusätzliches wie Kosten, Lizenz- oder Geschäftsmodell
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
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
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
LZ 3-2 Nenne drei Methodische Werkzeuge die bei der Architekturarbeit helfen können
- Business Use Cases
- Sceteches / Wireframes
- Rapid Prototyping
- Event Storming
LZ 3-2 Welche Analogie passt zum Vorlagen-basiertem vorgehen (Templates)
Schrank, jeder Teil der Architektur hat sein Fach / Platz im Schrank
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
LZ 2-6 Nenne Grundsätzliche Entwurfsprinzipien
- KISS
- YAGNI
- Separation of Concerns (SoC)
- Geheimnisprinzip
- Lose Kopplung
- Hohe Kohäsion
- Konsistenz
- Robustheitsprinzip
LZ 2-6 Arten von Kopplung
- Aufruf
- Benachrichtigung
- Erzeugung
- Besitz
Weitere:
- Vererbung
- Datenstrukturen
- Laufzeitumgebung
- Zeit
LZ 2-6 Was bedeutet Kohäsion im deutschen
Zusammenhangskraft, ein Maß für den inneren Zusammenhalt von Elementen (Bausteinen)
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
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
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
LZ 2-6 Was bedeutet Bausteine sind Lose gekoppelt / haben eine lose Kopplung
Es gibt wenige Abhängikeiten zwischen den Bausteinen
LZ 2-6 Warum ist Hohe Kopplung schlecht (im gegensatz zu Loser)
- Geringe Wartbarkeit / Änderbarkeit
- Hohe Fehleranfälligkeit
LZ 2-6 Was bedeutet Hohe Kohäsion (Zusammenhangskraft) für Bausteine
- Erledigt inhaltlich zusammengehörige Aufgaben
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
LZ 2-6 Wie funktioniert das Robustheitsprinzip
- Erwarte stets Fehler von anderen
- Selbst möglichst sauber bleiben
LZ 2-6 Wo muss man vorsichtig sein wenn man beim Robustheitsprinzip Fehler von anderen erwartet
- Keine Werte raten
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
LZ 2-1 Was ist Top-Down Design
Eine methodische Vorgehensweise bei der die Architektur vom groben ins Feine beschrieben wird
LZ 2-1 Welche Vorteile hat ein Top-Down Design, nenne zwei
- Überblick über Hauptkomponenten
- “Hohe Flugbahn”, daher geringes Risiko bei der Erstellung
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
LZ 2-1 Was ist Bottom-Up Design
Ein Methodik bei der vom feinen ins grobe designed wird
LZ 2-1 Vorteile Bottom-Up Design
- Schnelles erzielen von Ergebnissen
- Frühzeitiges Erkennen von Risiken
LZ 2-1 Nachteile Bottom-Up Design
- Teilergebnisse unter Umständen für weitere Schritte ungeeignet, da sie nicht ins Gesamtbild passen
LZ 2-1 Können Top-Down und Bottom-Up zusammen verwendet werden?
Ja beide ergänzen sich gegenseitig
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
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
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
Was ist bei Qualitätszielen mit Wechselwirkung gemeint
Sie können gegenseitig im Konflikt stehen
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
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
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.
LZ 2-4 Nenne drei Beispiele für Querschnittkonzepte
- Logging
- Autorisierung / Authentifizierung
- Reporting
- Batch
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. |
|————-|
LZ 2-4 Was sind Stereotypen
Modellierungskonstrukt, um Semantik von Bausteinen/Schnittstellen/Beziehungen klarer zu definieren
Ein Tag zur Kategoriesierung, quasi
LZ 2-4 Stereotypen können auch im Code bestimmte Namenskonventionen sein (Wahr/Falsch)
Wahr, zum Beispiel CustomerRepository pder Address*Repository
LZ 2-4 Wie können Stereotypen dokumentiert werden und wo werden sie am besten abgelegt
Wie: Tabelle mit Beschreibung
Wo: Glossar
Sind Konzepte wiederverwendbar für unterschiedliche Systeme?
Ja
Was sind Architekturtaktiken?
Feingranulare Konzepte welche zur Erreichung von Qualitätszielen beitragen
Nenne drei Beispiele für Architekturtaktiken
Ping / Echo
Heartbeat
Monitoring
Architekturtaktiken lassen sich bestimmten Qualitätszielen zuordnen um diese zu erreichen
Ja, z. B. Ping / Echo für Störung erkennen
LZ 3-8 Welche zwei Kategorien von Entwurfsentscheidungen gibt es
Irreversibel, kaum bis gar nicht änderbar
Reversibel, leicht änderbar
LZ 3-8 Mit welchem methodischen Werkzeug können Entwurfsentscheidung festgehalten werden
Mit Architecture Decision Record (ADR)
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
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
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
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
LZ 2-5 Beispiele für typische Schichten
GUI, Business Logik, Persistenz
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
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
LZ 2-5 Definition von Microservices?
Nicht eindeutig definiert, nur
“Unabhängig deploybare Services”
LZ 3-4 Welche vier wichtigen Sichten für Softwarearchitekturen gibt es
Kontextabgrenzung (Auch Kontextsicht)
Bausteinsicht
Laufzeitensicht
Verteilungssicht
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
LZ 3-4 Was ist zusätzlich zu Erklärung der Bausteinsicht immer erforderlich
Eine Tabelle mit Auflistung der Bausteine und zusätzlicher Beschreibung
LZ 3-7 Wie kommunizieren Bausteine
Bausteine kommunizieren über definierte Schnittstellen
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
LZ 3-7 Aufgaben bei Schnittstellenentwurf
- Formate bestimmen
- Übertragungsweg (technisches Protokoll)
- Ablauf
- Fehlerbehandlung
- Versionierung / Evolution
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
LZ 3-4 Was zeigt die Laufzeitsicht
Zeigt wie ein System eine bestimmte Aufgabe erfüllt
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
LZ 3-4 Welche Szenarien sollten mit der Laufzeitsicht dargestellt werden
Nur die wichtigsten!
- Wesentliche Anwendungsfälle
- Kritische Situationen bei bekannten Problemen
- Externe Schnittstellen
LZ 3-4 Über was genau gibt eine Laufzeitensicht Aufschluss
Über
- Datenfluss
- Paralellisierung
- Prozesse
- Betriebszustände
LZ 3-4 Nenne Ziele der Verteilungssicht
- Zeigt Struktur / Aufbau der beteiligten Hardware
- Zeigt welche Software auf welcher Hardware läuft
LZ 3-4 Nenne die wesentlichen drei Bestandteile einer Verteilungssicht
- Knoten (Verarbeitungseinheiten)
- Kanäle (Netze, Kommunikationskanäle)
- Zuordnung (Welcher Software-Baustein auf welcher Hardware)
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
LZ 3-4 Welchen Nutzen haben Sichten? Nenne zwei
- Systeme aus unterschiedlichen Perspektiven zeigen
- Beziehungen zwischen Sichten aufzeigen
LZ 3-3 UML-Diagramme für Kontextsicht?
- Komponentendiagram
- Paketdiagram
LZ 3-3 UML-Diagramme für Bausteinsicht?
- Komponentendiagramm
- Paketdiagram
- Klassendiagram
(Wie UML für Kontextsicht plus Klassendiagram)
LZ 3-3 UML-Diagramme für Verteilungssicht
- Verteilungsdiagram
LZ 3-3 UML-Diagramme für Laufzeitsicht
- Sequenzdiagramm
- Aktivitätsdiagramm
LZ 3-2 Dokumentation sollte bedarfsgerecht für Stakeholder und deren Informationsbedarf zugeschnitten sein (Wahr/Falsch)
Wahr
LZ 3-3 Welche Anforderungen gibt es an technische Doku
- Angemessenheit
- Korrektheit
- Wartbar
- Verständlich
- Inkrementell erstellt
Wo hilft Architekturbewertung
Bewerten steuert alle Übriegen Aufgaben, nur wenn ich weiß das ich am Ziel vorbei bin kann ich auch etwas dagegen tun
Welche zwei Arten von Architekturbewertungen gibt es
- Quantitative Bewertung
- Qualitative Bewertung
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.
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
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
Ein Konzept kann Einschränkungen für die Umsetzung vieler Bausteine definieren (Wahr/Falsch)
Wahr
