SAQT
...
...
Was sind Vorteile und Nachteile der Client/Server Architektur?
Vorteile
- Zentralisierung wichtiger, rechenintensiver oder sensibler Berechnungen im Server
- Thin Clients einfach in Verteilung und Wartung
- Rich Clients oft bei Server-Ausfall noch verwendbar
Nachteile
- Netzbelastung hoch (besonders bei Thin Clients)
- Verteilung der Funktionalität nicht immer einfach
- Grenzen der Skalierung bei sehr hohen Clientzahlen
Erkläre Peer-To-Peer (P2P)
- Gleichberechtigte, über ein Netzwerk verteilte Komponenten (Peers), die sowohl die Rolle von Clients als auch Servern wahrnehmen und sich Ressourcen teilen
- Eine Art von Konnektor («interpeer connection»)
- In der Regel das Internet
- Keine zentrale Kontrolle, Peers sind frei in der Kommunikation (jeder mit jedem)
- Lokalisierung der Peers durch
- dezentrale Kommunikation (Peers tauschen untereinander ihre Listen bekannter Peers aus) oder
- einen zentralen Service
Was sind die Vor- und Nachteile von P2P?
Vorteile
- Hohe Ausfallsicherheit (kein single point of failure)
- Rechenintensive Aufgaben können verteilt werden
- Seti@Home
Nachteile
- Auffinden und Erkennen von Peers in grossen Netzen
- Potentielle Gefahr des Zerfalls des P2P Netzes
- Nur bestimmte Gruppen von Peers kennen sich
- Fehlerbehandlung (Wer reagiert, wenn ein Peer seine Aufgaben falsch löst?)
- Keine garantierten Antwortzeiten
Wie definieren Sie Architektur aus Sicht des Arbeitsprozesses und der Arbeitsergebnisse des Architekten?
Architekturentwurf- Wie verläuft der Prozess:
- Denken in Systemen
- Welches sind die grundlegenden Systemelemente?
- Wie grenzen sie sich ab?
- Welche Beziehungen treten auf?
- Anwendung von Mustern
- Welche Muster treten in den Elementen und ihren Beziehungen auf?
- Bewertung des Systementwurfs
- Wieder oben anfangen
Erläutern Sie wie Qualitätsattribute als Kräfte bei der Lösungsfindung wirken.
...
Auf welchen Ebenen werden Architektur-relevante Entscheidungen getroffen? Nennen Sie Beispiele.
Ebenen (nach Zimmermann) Grundlegende Entscheidung
Exekutiv Ebene Architekturstil Konzeptuelle
Ebene Architekturmuster Technologie Ebene Java EE oder .NET?
Hersteller Ebene Oracle oder IBM? Microsoft?
Erkläre die Blackboard Archtektur.
- Ursprünglich aus der Künstlichen Intelligenz zur Lösung komplexer Probleme, für die kein deterministisches Lösungsverfahren existiert
- Kollaborative Problemlösung durch ansonsten unabhängige Programme
- Keine Aufrufe zwischen den Programmen, Kommunikation nur über Blackboard
- Zentrale Steuerungskomponente bewertet den Lösungsfortschritt auf dem Blackboard und aktiviert die verfügbaren Programme
Welches sind die ersten Schritte des Architekturentwurfs?
...
Wie kommen Sie von der Systemidee zur Struktur des Systems?
...
Womit dokumentieren Sie die Systemstrukturen?
...
Was verstehen wir unter einer Sicht und welche Sichten kennen Sie?
...
Welche Anforderungen erfüllen gute Sichten?
...
Was sollte in einer Architekturdokumentation enthalten sein?
...
Wie dokumentieren Sie Entscheidungen nach ISO 42010?
...
Was sind Vorteile und Nachteile von Blackboards?
Vorteile
- Einfache Integration komplexer Systeme
- Parallelisierung der Berechnungen möglich
- Moderne Variante: Tuple Space
Nachteile
- Keine Garantie der Lösungsfindung
- Finden der richtigen Kontrollstrategie ist schwierig
- Keine garantierten Antwortzeiten und Lösungen
Erkläre SOA aus Architektursicht.
- Spezifikation der Services und der verwendeten Datenformate und Kommunikationsprotokolle
- Entwurf der Applikationen als Orchestrierung von Services zur Erreichung bestimmter Geschäftsziele
- Service provider und service consumer
Erläutere die Schichten in der SOA Referenzarchitektur der OG
...
Grundprinzipien und Technologien von SOA.
- Vielzahl von Standards
- XML-basierte Datenformate
- SOAP/REST als wichtigste Protokolle
- Service-orientierte Systeme
- Modular
- Verteilbar
- Auffindbar
- Austauschbar
- Wiederverwendbar
Erläutere Vor- und Nachteile einer SOA Architektur.
Vorteile
- Sehr flexible Architekturform mit einfachem Grundmodell
- Systemfunktionalitäten als wiederverwendbare Assets verkapselt
- Binden von Services zur Laufzeit und Lookup in Registries möglich
- Vielzahl von ausgereiften Standards
- Verbindung von Business und IT
- Voraussetzung für Cloud, Mashups, …
Nachteile
- Inhärente Komplexität offener, dezentralisierter Systeme
- Vielzahl schwieriger Fragestellungen
- Service design, Interoperabilität, Standards
Unterschied Testen und Experimentieren?
Testen unterscheidet sich von Experimentieren dadurch, dass es beim Testen eine Erwartuntg gibt die belegt werden soll,
während das Ergebnis beim Experimentieren offen ist oder nur vermutet werden kann.
Wie definieren Sie die Architektur eines Softwaresystems?
Schnittstellen, Strukturen, Subsystem, Abgrenzungen Umwelt
Welche Elemente verbindet das Architektur-Denken?
- Anforderung
- Systemquliäten
- Randbedingungen
Worum ist Komplexitätsreduktion das wichtigste Ziel beim Entwurf einer Architektur?
- Wartbarkeit
- Erweiterbarkeit
In welchen wesentlichen Schritten sollte der Prozess des Architekturentwurfs ablaufen?
Iterativ:
1. Denken in Systemen
- Welches sind die grundlegenden Systemelemente?
- Wie grenzen sie sich ab?
- Welche Beziehungen treten auf?
2. Anwendung von Mustern
- Welche Muster treten in den Elementen und ihren Beziehungen auf?
3. Bewertung des Systementwurfs
Warum ist ein strukturiertes und inkrementelles Vorgehen sinnvoll?
- Reduziertes risiko
- Fehler werden früh gefunden
Welche Teildisziplinen der Software Architektur kennen Sie?
- Enterprise Architecture
- Solution Architecture
- Infrastructure Archtitecture
Unterschied zw. UseCase und UserStory?
UserStory
- Was, Warum
UseCase
- Wie
Ein hoher Detaillierungsgrad bei UserStories bedeutet?
Das nur wenig klärungsbedarf besteht und die wichtigsten Fragen beantwortet wurde, rsp. wenige Fragen offen bleiben.
Gute User Stories sind?
Sind INVEST:
- Independent
- Negotiable (flexible)
- Valuable
- Estimatable (usable for planning)
- Scaleable (klein und schätzbar)
- Testable
Team definiert Akzeptanzkriterien nach aufbereitung der Story, rsp. beim Grooming.
User Stories bearbeiten. 3 Stufig, inkrementeller Prozess. Erklären!
- Kurze beschreibung des Bedarfs
- Besprechung während des Backlock Groomings und der Iterationsplanung um die Details zu festigen
- Testen um zu Testen ob die Story zufriedenstellend umgesetzt werden kann
- Akzeptanzkriterien definieren
Fehler beim schreiben von User Stories?
- Zu Formal und zu detailiert
- Zu viele details führen zu Punkt 3; Fragen werden vergessen
- Technischer Task getarnt als Story
- Schwieriger zu priorisieren, evt. zu gross, verhindern Daily Build
- Konversation überspringen
- Ohne Akzeptanzkriterien: Risiko wesentliches zu überspringen
Wie werden Szenarien Spezifiziert?
- Stimulus source
- Stimulus
- Environment
- Artifact
- Response
- Response measure
- Szenarien machen nichtfunktionale Anforderungen SMART
- Mehrere Szenarien pro nichtfunktionaler Anforderung möglich
-
- Arten von Fehlern (mögliche Stimuli)
Omission
- kein Response auf einen Stimulus
Crash
- Omissions treten wiederholt auf
Timing
- Response tritt zu falscher Zeit ein (zu früh, zu spät)
Response
- falscher Respnse des Systems
Responses auf Fehler
- Prevention
- Detection & Isolation
- Recovery
- Logging des Fehlers
- Benachrichtigung von Benutzern und anderen Systemen
- Aktionen zur Schadensbegrenzung
- Einschränken der Verfügbarkeit oder Funktionalität des betroffenen Systems
Fehler Messen (3)
Mean Time to Recover (MTTR) - Zeitspanne bis ein ausgefallenes System wieder verfügbar ist
Mean Time to Failure (MTTF) - Zeitspanne bis zum Auftreten des nächsten Ausfall
Mean Time between Failure (MTBF) - Zeitspanne zwischen 2 Ausfällen
Erklärung: Interoperability (Interoperabilität, Integrierbarkeit)
- Grad in dem zwei oder mehr Systeme Information sinnvoll austauschen können
- syntaktischer Datenaustausch (Schnittstellen)
- semantische Dateninterpretation
- Mit wem? Mit was? Unter welchen Bedingungen?
Erklärung: Modifiability (Modifizierbarkeit, Veränderbarkeit, Erweiterbarkeit)
- Änderungen und Anpassungen vornehmen können
- Risiko?
- Was kann sich ändern?
- Wie wahrscheinlich ist eine Änderung?
- Wann passiert eine Änderung und durch wen?
- Was wird sie kosten?
Erklärung: Performance (Leistung)
- Systemreaktion in einer bestimmten Zeit auf ein bestimmtes Ereignis
- oft mit Anforderungen an Skalierbarkeit verbunden
- Ereignisse treten periodisch, stochastisch, sporadisch auf
- Messung des Response
- latency: Zeit zwischen Ereigniseintritt und Systemreaktion
- deadlines, throughput (Transaktionen/s), jitter (Varianz der Latency, Anzahl nicht verarbeiteter Events)
Erklärung: Security (Sicherheit)
- Fähigkeit eines Systems
- Daten und Informationen vor nichtberechtigtem Zugriff zu schützen, aber berechtigten Zugriff durch Benutzer (und andere Systeme) zuzulassen
- Informationsintegrität zu sichern (Schutz vor nichterlaubter Manipulation)
- für legitimierten Gebrauch verfügbar zu sein
- Angriffe erkennen, ihnen widerstehen, darauf reagieren und sich von ihnen erholen
- Z.B. "Denial of service" Attacke verhindert nicht, dass Bücher in einem Online Shop bestellt werden können
Erklärung: Testability (Testbarkeit)
- Einfachheit mit der Fehler im System festgestellt werden können
- "a system is testable, if it gives up its faults easily"
- Source: unit tester – Stimulus: code unit completed
- Artifact: code unit
- Environment: development
- response: written & executed tests with results
- measure: 85% path coverage in 3 hours
-
- 1 / 71
-
Flashcards
Wie definieren Sie die Architektur eines Softwaresystems?
Schnittstellen, Strukturen, Subsystem, Abgrenzungen Umwelt
Welche Elemente verbindet das Architektur-Denken?
- Anforderung
- Systemquliäten
- Randbedingungen
Worum ist Komplexitätsreduktion das wichtigste Ziel beim Entwurf einer Architektur?
- Wartbarkeit
- Erweiterbarkeit
In welchen wesentlichen Schritten sollte der Prozess des Architekturentwurfs ablaufen?
Iterativ:
1. Denken in Systemen
- Welches sind die grundlegenden Systemelemente?
- Wie grenzen sie sich ab?
- Welche Beziehungen treten auf?
2. Anwendung von Mustern
- Welche Muster treten in den Elementen und ihren Beziehungen auf?
3. Bewertung des Systementwurfs
Warum ist ein strukturiertes und inkrementelles Vorgehen sinnvoll?
- Reduziertes risiko
- Fehler werden früh gefunden
Welche Teildisziplinen der Software Architektur kennen Sie?
- Enterprise Architecture
- Solution Architecture
- Infrastructure Archtitecture
Unterschied zw. UseCase und UserStory?
UserStory
- Was, Warum
UseCase
- Wie
Ein hoher Detaillierungsgrad bei UserStories bedeutet?
Das nur wenig klärungsbedarf besteht und die wichtigsten Fragen beantwortet wurde, rsp. wenige Fragen offen bleiben.
Gute User Stories sind?
Sind INVEST:
- Independent
- Negotiable (flexible)
- Valuable
- Estimatable (usable for planning)
- Scaleable (klein und schätzbar)
- Testable
Team definiert Akzeptanzkriterien nach aufbereitung der Story, rsp. beim Grooming.
User Stories bearbeiten. 3 Stufig, inkrementeller Prozess. Erklären!
- Kurze beschreibung des Bedarfs
- Besprechung während des Backlock Groomings und der Iterationsplanung um die Details zu festigen
- Testen um zu Testen ob die Story zufriedenstellend umgesetzt werden kann
- Akzeptanzkriterien definieren
Fehler beim schreiben von User Stories?
- Zu Formal und zu detailiert
- Zu viele details führen zu Punkt 3; Fragen werden vergessen
- Technischer Task getarnt als Story
- Schwieriger zu priorisieren, evt. zu gross, verhindern Daily Build
- Konversation überspringen
- Ohne Akzeptanzkriterien: Risiko wesentliches zu überspringen
Wie werden Szenarien Spezifiziert?
- Stimulus source
- Stimulus
- Environment
- Artifact
- Response
- Response measure
- Szenarien machen nichtfunktionale Anforderungen SMART
- Mehrere Szenarien pro nichtfunktionaler Anforderung möglich
-
- Arten von Fehlern (mögliche Stimuli)
Omission
- kein Response auf einen Stimulus
Crash
- Omissions treten wiederholt auf
Timing
- Response tritt zu falscher Zeit ein (zu früh, zu spät)
Response
- falscher Respnse des Systems
Responses auf Fehler
- Prevention
- Detection & Isolation
- Recovery
- Logging des Fehlers
- Benachrichtigung von Benutzern und anderen Systemen
- Aktionen zur Schadensbegrenzung
- Einschränken der Verfügbarkeit oder Funktionalität des betroffenen Systems
Fehler Messen (3)
Mean Time to Recover (MTTR) - Zeitspanne bis ein ausgefallenes System wieder verfügbar ist
Mean Time to Failure (MTTF) - Zeitspanne bis zum Auftreten des nächsten Ausfall
Mean Time between Failure (MTBF) - Zeitspanne zwischen 2 Ausfällen
Erklärung: Interoperability (Interoperabilität, Integrierbarkeit)
- Grad in dem zwei oder mehr Systeme Information sinnvoll austauschen können
- syntaktischer Datenaustausch (Schnittstellen)
- semantische Dateninterpretation
- Mit wem? Mit was? Unter welchen Bedingungen?
Erklärung: Modifiability (Modifizierbarkeit, Veränderbarkeit, Erweiterbarkeit)
- Änderungen und Anpassungen vornehmen können
- Risiko?
- Was kann sich ändern?
- Wie wahrscheinlich ist eine Änderung?
- Wann passiert eine Änderung und durch wen?
- Was wird sie kosten?
Erklärung: Performance (Leistung)
- Systemreaktion in einer bestimmten Zeit auf ein bestimmtes Ereignis
- oft mit Anforderungen an Skalierbarkeit verbunden
- Ereignisse treten periodisch, stochastisch, sporadisch auf
- Messung des Response
- latency: Zeit zwischen Ereigniseintritt und Systemreaktion
- deadlines, throughput (Transaktionen/s), jitter (Varianz der Latency, Anzahl nicht verarbeiteter Events)
Erklärung: Security (Sicherheit)
- Fähigkeit eines Systems
- Daten und Informationen vor nichtberechtigtem Zugriff zu schützen, aber berechtigten Zugriff durch Benutzer (und andere Systeme) zuzulassen
- Informationsintegrität zu sichern (Schutz vor nichterlaubter Manipulation)
- für legitimierten Gebrauch verfügbar zu sein
- Angriffe erkennen, ihnen widerstehen, darauf reagieren und sich von ihnen erholen
- Z.B. "Denial of service" Attacke verhindert nicht, dass Bücher in einem Online Shop bestellt werden können
Erklärung: Testability (Testbarkeit)
- Einfachheit mit der Fehler im System festgestellt werden können
- "a system is testable, if it gives up its faults easily"
- Source: unit tester – Stimulus: code unit completed
- Artifact: code unit
- Environment: development
- response: written & executed tests with results
- measure: 85% path coverage in 3 hours
Erklärung: Usability (Benutzerfreundlichkeit)
- Wie einfach ist es für den Benutzer das System zu verwenden? Welche Unterstützung erhält er dabei?
- Teilaspekte
- Einarbeitung in ein System
- Verwendbarkeit/Bedienbarkeit
- Auswirkungen von Fehlerverhalten des Benutzers
- Anpassungsfähigkeit des Systems an den Benutzer
- Vertrauen und Zufriedenheit des Benutzers
- "App x kann 2 Minuten nach Download verwendet werden"
Wie gehen Sie mit einem unbekannten Qualitätsattribut um?
- Die Quellen der Anforderung befragen und das Attribut weiter aufschlüsseln - "was ist genau gemeint"?
- Konkrete Scenarien für das Attribut sammeln
- Die gesammelten Stimuli, Responses, Measures verallgemeinern – was ist der wesentliche Kern des Attributs?
- Taktiken und Muster für die Umsetzung finden
- Wie können die geforderten Responses erreicht werden?
- Woran kann eine Architektur in Bezug auf das Attribut scheitern und wie kann ich das verhindern?
Wie müssen Anforderungen im generellen formuliert sein:
SMART
- Spezifisch
- Messbar
- Akzeptiert
- Realistisch
- Terminiert
Warum sind Akzeptanzkriterien in User Stories wichtig?
Definition of Done:
Ohne Akzeptanzkriterien besteht ein erhöhtes Risiko, wesentliche Funktionalitäten zu übersehen oder falsch zu interpretieren. Die Software wird an den Bedürfnissen des Kunden vorbei entwickelt.
Warum sollten Use Cases auf unterschiedlichen Detaillierungsstufen formuliert werden? Welche Stufen sind sinnvoll?
Zielhierarchie: Funktionale Abhängigkeiten
Kommunikation auf verschiedenen Leveln: (sichten)
- Stakeholder (Weiss)
- Management (blau)
- Technisch (indigo/schwarz)
Wie hängen Ziele und Schritte in einem Use Case zusammen?
Ziel: Was soll erreicht werden.
Schritte: Wie sollen die Ziele erreicht werden.
Welche Rolle spielen nichtfunktionale Anforderungen und Qualitätsattribute im Architekturentwurf?
Spielen die entscheidende Rolle, bestimmen die Architektur.
Nennen Sie Beispiele für Qualitätsattribute.
- Verfügbarkeit
- Sicherheit
- Leistung
- Benutzbarkeit
- Skalierbarkeit
Wie beschreiben Sie ein Qualitätsattribute mit Hilfe von Szenarien?
- 1. Stimulus source
- 2. Stimulus
- 3. Environment
- 4. Artifact
- 5. Response
- 6. Response measure
Wie gehen Sie mit einem Ihnen unbekannten Qualitätsattribut um?
- Die Quellen der Anforderung befragen und das Attribut weiter aufschlüsseln - "was ist genau gemeint"?
- Konkrete Scenarien für das Attribut sammeln
- Die gesammelten Stimuli, Responses, Measures verallgemeinern – was ist der wesentliche Kern des Attributs?
- Taktiken und Muster für die Umsetzung finden
- Wie können die geforderten Responses erreicht werden?
- Woran kann eine Architektur in Bezug auf das Attribut scheitern und wie kann ich das verhindern?
Welche Beziehung besteht zwischen einem Qualitätsattribut und einem Use Case? Wie würden Sie Informationen zu einem Qualitätsattribut in einem Use Case hinzufügen?
Use Case-specific non-functional requirements
oder
Special Considerations
Nennen Sie Beispiele für grundlegende Prinzipien für einen guten Architekturentwurf.
- Lose Kopplung (Loose Coupling)
- Hohe Kohäsion (High Cohasion)
- Entwurf für Veränderung (Design for Change)
- Trennung der Verantwortlichkeiten (Separation of Concerns)
- Geheimhaltung (Information Hiding)
- Abstraktion
- Modularität
- Rückverfolgbarkeit (Traceability)
- Selbstdokumentation
- Inkrementalität
Was ist ein Architekturprinzip?
Architektur-Prinzipien repräsentieren bewährte Grundsätze, die bei der Gestaltung einer Architektur zur Anwendung kommen sollten
2 Hauptziele:
- Reduktion der Komplexität
- Erhöhung der Flexibilität/Änderbarkeit
Womit beschäftigen sich Taktiken nicht?
- Beschäftigen sich nicht mit Tradeoffs (Kompromissen)
- Betrachten es isoliert, nicht mit den Zusammenhängen
- Beschäftigen sich nicht mit der Funktionalität
Was verstehen Sie unter einer Taktik?
Eine Taktik ist eine Entwurfsentscheidung, die Einfluss nimmt auf die Realisierung der Reaktion eines Qualitätsattributszenarios.
Konkrete Entwurfsmuster für nichtfunktionale Anforderugnen.
Erläutern Sie Beispiele für Taktiken zu einem Qualitätsattribut.
- Warum Heartbeat für Server
- Monitoring
- Overhead reduzieren
=> Beispiele zum lösen konkreter Probleme bringen. Warum das obige?
Welche wesentlichen Designentscheide im Zusammenhang mit nichtfunktionalen Anforderungen trifft ein Architekt?
Erläutern Sie diese an einem Beispiel.
1. Zuordnung von Verantwortlichkeiten
- Welche Elemente im System sind für welche Funktionen und Qualitätsattribute verantwortlich?
2. Koordinationsmodel
- Wie interagieren welche Elemente? Welche dürfen nicht interagieren?
3. Datenmodell (inkl. Datenhaltung)
4. Resourcenmanagement
- Wie werden welche Resourcen "gemanaged", "geshared"? Welcher Resourcenbedarf besteht?
5. Zuordnungen von Architekturelementen (mapping)
- Innerhalb der Architektur: z.B. Module und Laufzeitprozesse
- Zur Umgebung: z.B. Prozesse und CPU Elemente
6. Binding time decisions
- Variabilität in der Architektur
- z.B. Auswahl von Modulen durch parametrisierbares Makefile
- z.B. Protokoll negotiation erlaubt im Koordinationsmodell?
- z.B. ein Appstore, der die App automatisch passend zur Smartphone Version auswählt
7. Technologiewahl – Vorgegeben als Constraint oder Wahl des Architekten
Erläutern Sie bekannte Architekturstile.
- Schichten (Layers, Tiers)
- Pipes & Filters
- Verteilte Systeme
- Client/Server
- P2P
- Blackboard
- SOA
Was verstehen Sie unter einem Architekturstil und einem Architekturmuster?
Architekturmuster
A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution.
Architektur Stile (Grundlegende Muster)
In der Literatur existieren unterschiedliche Auffassungen, welche grundlegenden Muster als Stil betrachtet werden
Erläutern Sie Beispiele für Integrationsmuster.
- File Transfer
- Anwendungen erzeugen Dateien für gemeinsam verwendete Daten, die ausgetauscht werden
- Shared Database
- Anwendungen lesen und schreiben in eine gemeinsame Datenbank
- Remote Procedure Invocation
- Anwendungen stellen Schnittstellen zur Verfügung, die extern aufrufbar sind
- Messaging
- Anwendungen verwenden ein gemeinsames Messaging System für Datenaustausch und Aufruf
