Flashcards
iSAQB Foundation Level Inhalte
Cards in this deck (200)
- 1softwareintensives SystemMenge von Bausteinen
vollständig oder wesentliche Teile sind Software
essentielle Aufgaben zur Erfüllung des Zwecks - 2Rolle der Softwarearchitekturgrobes Konzept
systemweite Abstraktion
Struktur der Strukturen
Wiederverwendung abstrakter Ideen - 3Vorteile der Softwarearchitekturlangfristige Planung
verständlich
analysierbar
wiederverwendbar - 4Arten von ArchitekturGeschäftsarchitektur
Prozessarchitektur
Integrationsarchitektur
Anwendungsarchitektur
Infrastrukturarchitektur - 5Inhalte der GeschäftsarchitekturStrategie
Produkte
Dienstleistungen - 6Inhalte der ProzessarchitekturGeschäftsprozesse
Organisationseinheiten
Rollen - 7Inhalt der IntegrationsarchitekturBebauungsplan
fachliche Services
Integration - 8Inhalt der AnwendungsarchitekturModularisierung
Wiederverwendung
Schnittstellen - 9Inhalt der InfrastrukturarchitekturServer
Plattformen
Netzwerkkomponenten - 10Definition: Softwarearchitekturgrundlegende Prinzipien und Regeln für die Organisation eines Systems sowie dessen Strukturierung in Bausteinen und Schnittstellen und deren Beziehung zueinander wie zur Umgebung
Richtlinien für den Systemlebenszyklus angefangen bei Analyse über Entwurf und Implementierung bis zu Betrieb und Weiterentwicklung wie auch für Entwicklungs- und Betriebsorganisationen
Beschreiben der Lösung, nicht Lösung selbst - 11Rolle von Software-Architektur im EntwicklungsprozessProjektleitung/-management: Aufgabenplanung
Anforderungsanalyse: funktionale & nicht-funktionale Anforderungen als Basis für Architektur
Implementierung: Anleiten durch Vorgaben
Qualitätssicherung: Testplanung & Überprüfung der Anforderungen
Hardwareentwicklung: gegenseitige Beeinflussung
Betrieb: bestimmt Laufzeitumgebung - 12Nutzen von Software-ArchitekturBrücke zwischen Analyse und Realisierung (Abbildung von Anforderungen auf Strukturen)
Abstraktion (Modellbildung)
Macht Komplexität beherrschbar und verständlich
Basis für Qualität -> Flexibilität & Erweiterbarkeit - 13Definition: BausteinAbstraktion von speziellen Programmierkonstrukten oder Beschreibungselementen
- 14Arten von BausteinenPakete, Packages, Namespaces
Klasse, Modul, Funktion, Prozedur
Komponente, Programm
Skript
Bibliothek, Framework
Datenstruktur, DB-Tabelle
Layout-/Mappingdefinition - 15Aspekte von BausteinenExport und Import von Schnittstellen (Contract)
Kapselung & Austauschbarkeit
Konfiguration & hierarchische (De-)Komposition (Subbausteine) - 16Arten von SichtenBlackbox
Whitebox
Greybox - 17Blackbox-Sicht (Außensicht)nur Schnittstellen mit Funktionalität (Dienste)
kein Innenleben (Geheimnisprinzip)
Sicht des Architekten - 18Whitebox-Sicht (Glasbox-/Innensicht)innere Struktur und Zerlegung in Subbausteine
Arbeitsweise der Subbausteine und Delegation der Schnittstellen an das Innenleben
Sicht des Implementierers - 19Greybox-Sicht (Konfigurationssicht)Ausschnitt der inneren Struktur (Konfiguration, Parameter, Varianten)
- 20Verantwortung des Architekten bei Blackbox-BausteinenErfüllung von funktionalen und nicht-funktionalen Anforderungen
Methodensignaturen und Datenformate der Schnittstelle
Ausmaß der Kopplung mit anderen Bausteinen - 21Verantwortung des Architekten bei Whitebox-ZerlegungEnthaltene Blackbox-Bausteine
Begründung der Zerlegung
Abhängigkeiten & Testbarkeit der enthaltenen Blackbox-Bausteine - 22Definition: Schnittstellewohldefinierter Zugangspunkt zum System oder dessen Bausteinen
Eigenschaften des Zugangspunktes (Attribute, Daten, Funktionen)
präzise mit notwendigen Aspekten (Syntax, Datenstrukturen, funktionales Verhalten, Fehlerverhalten, nichtfunktionale Eigenschaften, Nutzungsprotokoll, Technologien, Randbedingungen & Semantik) - 23Postel's LawSei strikt bei dem, was du tust, und nachsichtig bei dem, was du von anderen akzeptierst.
- 24Orte der Schnittstellendefinition
- 25Ziele von Software-ArchitekturenLanglebigkeit
Wartbarkeit
Änderbarkeit/Erweiterbarkeit
Energieeffizienz
Qualitätsmerkmale (oben) als Differenzierung ggü. Funktionalität - 26Aufgaben des Software-Architektenkonstruieren und entwerfen
absichern der Erfüllung der Anforderungen
beraten
dokumentieren
vereinfachen
kommunizieren
bewerten
Diplomatie und Akrobatik
Mut (nicht waghalsig) - 27AbwägungenKomplexität <--> Einfachheit
Kosten & Termine <--> Leistung
neue Tech. <--> etablierte Tech.
min. Schnittstellen <--> enge Integration
strikte Kontrolle <--> agile Entscheidungen
Top-Down <--> Bottom-Up
- 28angrenzende Rollen an den Software-ArchitektenAuftraggeber
Projektleiter
Anwender
Entwickler
Qualitätsmanager
Architecture-Board
Businessanalyst
Sicherheitsexperte
Betrieb - 29Informationen sammelnMaterialien zu ähnlichen Problemen
Wiederverwendung (eigene Erfahrung, andere Projekt im Unternehmen, Internet, Literatur, Entwurfsmuster)
Misstrauen ggü. unbekannter Lösungen
neue Ideen nicht immer genial (schlechte Recherche) - 30Fragen zu LösungsideeWas ist die Kernaufgabe des Systems?
Wie wird das System genutzt?
Wer nutzt das System?
Welche Schnittstellen gibt es?
Wie verwaltet das System Daten?
Wie wird das System gesteuert?
-> Dokumentation (max. eine A4 Seite) - 31Was ist die Kernaufgabe des Systems?Kernaufgabe und Verantwortlichkeit
positiv & Begriffe aus Fachdomäne
zusätzlich wichtigste Begriffe oder Aspekte der Fachdomäne
ggf. aus der Anforderungsanalyse übernehmen
Abstimmung mit Auftraggeber/Kunde - 32Wie wird das System genutzt?interaktive Online-Systeme (operationale Systeme): Geschäftsprozesse, Operation auf Daten abgebildet in UI
Entscheidungsunterstützungssysteme: Kopie der Daten (Data Warehouse) lesenden Zugriff via Queries
Hintergrundsysteme (Offline, Batch): Datenmanipulation, Vor- & Nachbereitung von Daten
eingebettete Systeme: enge Verzahnung mit Hardware
Echtzeitsysteme: Operation innerhalb garantierter Zeit beendet - 33Wer nutzt das System?Benutzer der Kernfunktionalität
Admin & Betreiber
Benutzer von Sonderfunktionen
negativ-gesinnte Stakeholder
Nutzerschnittstellen (Bildschirm/Formular, Expertenarbeitsplatz, Konsole/CMD, spezielle Hardware)
Nutzungsgruppen-UI? - 34Welche Schnittstellen gibt es?externe Systeme (Export/Import)
Stabilität/Fehlertoleranz
Funktionen oder Daten
Semantik
Synchronität
Performance
Änderbarkeit der anderen Seite - 35Wie verwaltet das System Daten?Hauptspeicher, Dateien, DB
Entscheidungsaspekte:
Persistenz & Volumen
Kosten (Lizenz, Wartung)
Performance (paralleler Zugriff)
Erweiterbarkeit
Datenintegrität
Unterstützung von Transaktionen
Anfragesprache
Sicherheit
Wiederherstellbarkeit - 36Wie wird das System gesteuert?ereignisgetrieben: Baustein für Eingaben und Klicks ruft System auf
prozedural: Baustein des Systems ruft sequenziell weitere Bausteine auf
parallel: mehrere unabhängige Bausteine reagieren auf Ereignisse / Anfragen - 37Systemidee kommunizierenAbstimmung mit Auftraggebern und Projektleitung
Kommunikation zu allen Beteiligten
Indikator für Risiken falls Beschreibung von Aspekten ungenau - 38Einflussfaktoren und Randbedingungen klären
- 39typische Risikenenger Zeitplan
eingeschränkte Verfügbarkeit/Eignung von Resourcen (inkl. Personal)
eingeschränkte Verfügbarkeit von Wissen
neue Produkte, geänderte Lizenz-/Geschäftsmodelle/Kooperationen
organisatorische Änderungen
kritische Schnittstellen zu externen Systemen
technische Infrastruktur/externe technische Entscheidungen
schlecht gestellte Anforderungen (widersprüchlich/nicht priorisiert)
neue/sich ändernde Anforderungen (fachlich oder regulatorisch) - 40Risiken identifizierenkeinen systematischen oder deterministischen Weg zur Identifikation
Erfahrung und Sachvertand
Techniken (Brainstorming mit Beteiligten, Diskussion mit Personen anderer Projekte, Risikomanagement der Projektleitung, Wechselwirkung/gegenseitige Verstärkung) - 41QualitätseigenschaftenFunktionalität
Zuverlässigkeit
Benutzbarkeit
Effizienz
Sicherheit
Kompatibilität
Wartbarkeit
Portierbarkeit - 42Qualitätsmerkmale der Eigenschaft FunktionalitätEignung
Verwendbarkeit
Genauigkeit
Interoperabilität - 43Qualitätsmerkmale der Eigenschaft ZuverlässigkeitReife
Fehlertoleranz
Ausfallsicherheit
Datensicherheit - 44Qualitätsmerkmale der Eigenschaft BenutzbarkeitVerständlichkeit
Erlernbarkeit
Bedienbarkeit
Attraktivität - 45Qualitätsmerkmale der Eigenschaft EffizienzZeitverhalten
Ressourcennutzung - 46Qualitätsmerkmale der Eigenschaft SicherheitIntegrität
Vertraulichkeit
Nachweisbarkeit
Authentizität
Verantwortlichkeit - 47Qualitätsmerkmale der Eigenschaft KompatibilitätAustauschbarkeit
Interoperabilität
Compliance - 48Qualitätsmerkmale der Eigenschaft WartbarkeitAnalysierbarkeit
Änderbarkeit
Erweiterbarkeit
Stabilität
Testbarkeit - 49Qualitätsmerkmale der Eigenschaft PortierbarkeitAnpassbarkeit
Installierbarkeit
Ersetzbarkeit
Konfigurierbarkeit - 50Produktkarton mit BeipackzettelWie heißt das Produkt?
Was entwickeln wir? (ein Satz)
Wem nützt es und wozu ist es gut?
Was sind die wesentlichen Features?
Was ist das zentrale Verkaufs-/ Nutzungsargument? (Claim/Slogan)
Welche Qualitätsmerkmale (Ziele) sind besonders wichtig?
Welche Risiken sind mit dem Projekt verbunden? - 51Top-Down-EntwurfZerlegung in Teilprobleme (Dekomposition)
Vision des Gesamtsystems - 52Bottom-Up-EntwurfZusammenbau von Teillösungen (Komposition)
fachliche Klassen und Teilfunktionen - 53Vorteile Top-Down-Entwurfgutes Problemverständnis
maschinen- und sprachunabhängig
kein sich-im-Detail-verlieren
saubere Schnittstellen/Konsistenz
Entwurf im Produkt erkennbar - 54Nachteile Top-Down-Entwurfkritische Integration am Ende
Übersehen von existierenden (Teil-)Lösungen
gravierende Änderungen bei spät erkannten Problemen
spätes Feedback über Richtigkeit - 55Vorteile Bottom-Up-Entwurfhoher Wiederverwendungsgrad
hohe Funktionssicherheit durch inkrementelle Tests
schrittweise Integration
Beginn mit vermuteten Teilproblemen - 56Nachteile Bottom-Up-Entwurfpotentiell nicht alles benötigt
Orientierung an technischen Gegebenheiten statt Benutzeranforderung
Gefahr der frühzeitigen Optimierung
Wildwuchs - 57Architekturebenenfachliche Architektur
Architekturstile
technische Infrastuktur
technische Architektur
auf allen Ebenen: Programmdesign - 58fachliche UmgangsformenArt und Weise der Handhabung von Gegenständen
Welche Informationen werden am Gegenstand abgelesen?
Welche Veränderungen werden am Gegenstand vorgenommen?
Welche Aktionen werden ausgelöst?
(ohne Zerstörung/Transformation) - 59Entwurf nach ZuständigkeitenModularität
Separation of Concerns
Kohäsion
Single Responsibility Principle
Law of Demeter - 60Entwurfsprinzipiengroße Bausteine vermeiden
Don't Repeat Yourself (DRY)
Keep It Simple, Stupid! (KISS)
Schnittstellen verbergen Interna (Geheimnisprinzip): Kapselung & Lokalität - 61Law of Demeter"If you delegate, delegate fully!"
"Don't talk to a stranger!"
Fluent Interface - 62Ziele von gutem Designgeringe Kopplung
Zyklenfreiheit - 63KopplungMaß der Abhängigkeit eines Bausteins von der Umgebung
Vorteile bei geringer Kopplung:
leichte Anpassbarkeit
Verständlichkeit
gute Testbarkeit
hohe Wiederverwendbarkeit - 64ZyklenfreiheitAcyclic Dependency Principle (ADP)
Auswirkung auf:
Wartbarkeit
Austauschbarkeit
Testbarkeit
Einstiegspunkt beim Analysieren - 65fachliche ArchitekturansätzeTransaction Script
Table Module
Domain Model - 66Transaction Scriptgut für einfache Probleme
einzelne Prozeduren
Prozedur pro Anfrage vom UI
Transaktionsklammern korrespondieren mit Prozedur
direkte Kommunikation (max. schlanker Adapter)
kein OO, sondern prozedural
große Anzahl und Duplicate Code bei großer Komplexität
Mix von Fach- und Techcode
kaum nachvollziehbare Abhängigkeiten - 67Table ModuleKlasse pro DB-Tabelle
Algorithmen direkt auf ResultSet
kein OO, sondern DB-zentriert
große Anzahl und Duplicate Code bei großer Komplexität
Mix von Fach- und Techcode
kaum nachvollziehbare Abhängigkeiten - 68Domain Modeltypische OO-Modellierung
Verwendung von Konzepten wie Kapselung, Lokalität & Delegation
Trennung von Fach- und Techcode
Kapselung von Daten & Algorithmen
Polymorphie statt Conditionals
Funktionalität am besten geeigneten Objekt
komplexer Kern von fachlichen Klassen - 69CRC-KartenKlassen/Komponentenname: Begriff des Anwendungsgebiets/Fachsprache
Verantwortlichkeit: erbrachte Dienstleistungen, Angebot an Klienten
Zusammenarbeit: Nennung anderer Komponenten, deren Dienstleistung genutzt wird, um eigene Dienstleistung zu erbringen (Delegation) - 70Vorgehen bei CRC-Karten-ModellierungFachbegriffe aus Use Cases und Glossaren
Was tun Akteuere mit den Dingen?
Rollenspiel um Lücken zu finden bei der Nachstellung der Use Cases - 71Vermeiden bei CRC-Karten-ModellierungKlassen mit zu viel Verantwortlichkeit
Klassen ohne Verantwortlichkeit
Klassen mit unbenutzter Verantwortlichkeit
Klassen mit unzusammenhängender Verantwortlichkeit
gleiche Verantwortlichkeit in mehreren Klassen
Klassen ohne Zustand
aber: nicht zu früh rauslassen, lieber zu viel als zu wenig - 72Architekturstilprinzipielle Lösungsstruktur, die durchgängig und weitgehendem Verzicht auf Ausnahmen angewandt werden sollte
Microservice
Schichtenarchitektur
Mustersprache - 73SchichtungStandardschichten: Präsentation, Applikation, Fachdomäne, Infrastruktur
fachliche Schichtung als Module mit je allen Schichten
höhere Schichten nur Beziehung zu unter ihr liegenden Schichten
Schnittstellen zischen Schichten
strenge Schichtung: nur direkt darunter liegende Schicht - 74Vorteile von SchichtungFlexibilität
Unabhägigkeit
Austauschbarkeit
minimierte Abhängigkeiten
leicht verständlich - 75Nachteile von Schichtungnegativer Einfluss auf Performance (Gegenmaßnahme: Layer-Bridging)
manche Änderung schlecht unterstützt (Anpassung in vielen Schichten) - 76Schwierigkeiten & Lösungen für die Infrastrukturschichtenthält Logging Framework, Libraries, OR-Mapper, ...
Zugriffe aus allen Schichten notwendig
Umwandlung in fachliches Modul (Libraries/Framework nur auf entsprechender technischer Schicht) - 77Effekte durch Zwang zur ZyklenfreiheitBuild-System verbietet Zyklen
Monolith mit vielen Satelliten
Pipes & Filter für Datenfluss (Trennung fachlicher und technischer Bestandteile) - 78Trennung fachlicher und technischer Bestandteilejeder Baustein nur für einen der beiden Aspekte zuständig
Anforderungen ändern sich getrennt voneinander
Vorteile: Modularisierung, Wartbarkeit, Verständlichkeit, bessere Kommunikation zwischen Domänenexperten und Sortwareexperten - 79Architekturen die Fachlichkeir und Technik trennenHexagonale Architektur (Adapter verbinden technische Schnittstellen mit fachlichem Anwendungskern)
Onion / Clean Architecture
Domain Driven Design - 80Elemente der Domain-Schicht
- 81DDD EntitiesKernobjekte
Zustand anhand von ValueObjects
Konsistenz des Zustands
unveränderliche Identität
klar definierter Lebenszyklus
(immer) persistent
anwendungsfachlich - 82DDD ValueObjectskeine eigene Identität
beschreiben Zustand anderer Objekte
unveränderlich
können aus anderen ValueObjects bestehen, nie aus Entities
anwendungsfachlich - 83DDD Servicesstellen Abläufe oder Prozesse dar, die nicht von Entitäten ausgeführt werden können
zustandslos
Parameter und Ergebnisse der Operationen sind Entities und ValueObjects
anwendungsfachlich - 84DDD FactoriesErzeugung von Aggregates, Entities und ValueObjects
innerhalb der Domäne
kein Zugriff auf technische Bausteine
anwendungsfachlich - 85DDD Repositorieskapseln technische Details der Infrastukturschicht ggü. der Domänenschicht
beschaffen Objektreferenzen von Entities, die ais DB gelesen werden müssen
Transformationssoftware - 86DDD Aggregatesvernetze Entities & ValueObjects
einzige Entity als Wurzel
Änderung als Einheit
fachliche Konsistenz und Integrität
anwendungsfachlich - 87DDD SchichtenarchitekturUI: Eingaben/Benutzerkommandos, Darstellung
Application: Geschäftsprozesse, Domain-Schicht kann Aufgabe übernehmen
Domain: Fachdomäne, siehe DDD Karten
Infrastruktur: technische Dienste, wie Persistenz, Sicherheit, Kommunikation mit anderen Systemen - 88Werkezug-Material-AnsatzErweiterung DDD um UI
Werkzeug: verkörpert fachliches Prinzip, Untersuchen und Ändern von Entities, neues Konzept, da kein Pendant in Domain, Freiraum in Bearbeitung
Automaten: wiederkehrende Routine, definierte Folge von Schritten, festes Ergebnis, keine äußere Eingriffe - 89Conway's Law"Organizations, which design systems, are constrained to produce designs, which are copies of the communication structures of these organizations. They are congruent!"
z.B.: Wenn 4 Teams einen Compiler bauen, bekommt man einen 4-Phasen Compiler - 90Zuordnung Bausteine zu TeamsKomponenten-Teams: Wenn ein Team mehrere Bausteine umsetzt, werden diese verschmelzen
Feature-Teams: Bausteine aus mehreren Schichten werden verschmelzen - 91Monolith vs. MicroservicesMonolith: alle Funktionalität in einem Prozess, Skalierung durch mehrere Server
Microservices: Jedes Element der Funktionalität ist ein eigener Server, Skalierung durch Verteilung und Replikation der einzelnen Services - 92Entwurfsmusterwiederkehrende Probleme und bewährte Lösungen
standardisierte Arrangements von Bausteinen
lokale Anwendung
mehrere pro System - 93Ziele von EntwurfsmusternKopplung bei Erzeugung aufheben (Factory)
Schnittstellenanpassung (Adapter, Bridge, Fassade)
Kapselung (Proxy)
dynamische und transparente Erweiterung (Decorator)
Benachrichtigung ohne Addresat zu kennen (Observer) - 94Factory-PatternSchnittstelle zum Erzeugen von Objekten
- System unabhängig von Objekten (Bibliothek, Framework)
- Systemkonfiguration mit Produktfamilie
- Wahrung der Konsistenz bei verwandten Produkten
- Blackbox-Bibliothek - 95Vor-/Nachteile des Factory-Patterneinfacher Austausch der konkreten & abstrakten Fabriken
Anwendung nur einer Produktfamilie sichergestellt
Erweiterung komplex, da Schnittstellen in allen Subklassen ergänzt werden müssen - 96Adapter-PatternAnpassung einer Schnittstelle an die Erwartungen des Klienten. Überbrückung von inkompatiblen Schnittstellen.
- existierende Klasse soll wiederverwendet werden aber Schnittstelle passt nicht
- Erstellung wiederverwendbarer Klasse
- Wiederverwendung von Unterklassen ohne Spezialisierung aller Schnittstellen - 97KlassenadapterAnpassung an genau eine Zielklasse (keine Unterklassen)
Verhalten adaptierter Klasse kann geändert werden
nur ein Objekt, keine Durchreicheoperationen - 98ObjektadapterAdapter kann adaptierte und Subklassen anpassen
begrenzte Verhaltensänderung ohne Unterklassenbildung - 99BrückenmusterEntkopple Abstraktion von Implementierung für unabhängige Variierung
- Implementierung soll zur Laufzeit ausgewählt werden
- Abstraktion und Implementierung durch Unterklassen erweiterbar
- verschiedene Kombinationen von Abstraktion und Implementierung
- Implementierung hat keine Auswirkung auf Klienten
- Nutzung von mehreren Objekten - 100Vor-/Nachteile des Brückenmusters- Entkoppelt Schnittstelle & Implementierung -> keine Abhängigkeiten von der Implementierung
- keine Neuübersetzung der Abstraktion oder der Klienten bei Änderung
- Förderung von Schichtenbildung -> besser strukturierte Systeme
- Abschirmen der Klienten vor Implementierungsdetails - 101Fassadenmuster- Anbieten einer einfachen Schnittstelle zu komplexem Subsystem
- einfache Sicht auf ein Subsystem für Klienten
- Aufteilung eines Systems in Schichten mit definierten Eintrittspunkten - 102Vor-/Nachteile des Fassadenmusters- verringerte Komplexität durch Subsysteme
- erleichterte Benutzung komplexer Subsysteme durch Minimierung der handhabbaren Objekte
- minimierte Kommunikation und Abhängigkeit zwischen Subsystemen (verringerte Kopplung)
- Änderung von Subsystemen ohne Neuübersetzung des Gesamtsystems - 103ProxymusterZugriffskontrolle über Stellvertreterobjekt
anpassungsfähige und intelligente Referenz auf ein Objekt
- teure Objekte erst auf Verlangen initialisieren (virtueller Proxy)
- Kontrolle des Zugriffs auf Originalobjekt (Schutzproxy)
- lokaler Stellvertreter für Objekt aus anderem Adressraum (Remote Proxy)
- Verfolgung von Referenzen mit zuätzlichen Aktionen (Smart Pointer) - 104Vor-/Nachteile des ProxymustersEbene der Indirektion für Objektzugriff
- Remote-Proxy versteckt anderen Adressraum
- virtueller Proxy kann Optimierungen ausführen
- Schutzproxies und Smart Pointer ermöglichen zusätzliche Verwaltungsaufgaben
- echtes Objekt nicht zwingend bekannt, kann auch für Familien von echten Objekten verwendet werden - 105Dekorierermuster (Decorator Pattern)dynamische Erweiterung von Objekten als alternative zur Unterklassenbildung
- Erweiterung einzelner Objekte ohne Einfluss auf andere Objekte
- zusätzliche Funktionalität soll entfernt werden können
- Unterklassenbildung unpraktisch (z.B. viele Klassen nötig um alle Kombinationen abzudecken) - 106Vor-/Nachteile des Dekorierermusters- höhere Flexibilität im Vgl. zu Vererbung
- keine Überfrachtung der hochstehenden Klassen in der Hierarchie
- Dekorierer umschließt ist aber nicht identisch
- oft erhöhte Objektanzahl
- benötigt eine leichtgewichtige Oberklasse
- statt oberflächlicher Veränderung kann mit Strategiemuster auch innere Logik geändert werden - 107Beobachtermuster (Observer Pattern)1:n-Beziehung zwischen Objekten, so dass Zustandsänderung abhängige Objekte benachrichtigt
- Geberobjekt kennt Schnittstelle des Nehmerobjektes nicht
- Vermeidung von wechselseitige Beziehungen, welche Bildung von Subsystemen & Komponenten erschwert
- Entkopplung von Komponenten - 108M(odel)-V(iew)-C(ontroller) MusterModel: Datenhaltung/Zustand
View: Darstellung der Daten des Models
Controller: Steuerung des Verhaltens
- Controller wählt View
- View fragt Model ab
- View sendet Input an Controller
- Controller aktualisiert Model
- Model informiert View über Änderungen - 109Broker (Vermittler)-MusterStrukturierung verteilter Softwaresysteme
- Vermittler zur Koordination der Kommunikation
- Dienste für Hinzufügen, Entfernen, Auswechseln, Aktivieren und Suchen
- Klient weiß nicht ob lokale oder entfernte Komponente
- Grundlage von CORBA (Common-Object-Request-Broker-Archtitecture) - 110Vorteile Brokermuster- Standortunabhängig: Vermittler kümmert sich um Auffinden der Services
- Komponenten leicht zu ändern wenn Schnittstellen stabil
- Portierbarkeit eines Brokersystems
- Interoperabilität zw. Brokersystemen
- Wiederverwendung von Komponenten - 111Nachteile Brokermuster- eingeschränkte Effizienz
- hohe Netzwerklast
- niedrige Fehlertoleranz
- schwieriges Testen/Debuggen
- Interoperabilität zw. Brokern nicht erreicht
- Wiederverwendung meist nur innerhalb des Servers - 112SOLIDS ingle Responsibility Principle
O pen Closed Principle
L iskov Substitution Pronciple
I nterface Segregation Principle
D ependency Inversion Principle - 113Single Responsibility Principle (SRP)Jede Klasse nur eine fest definierte Aufgabe
- 114Open/Closed Principle (OCP)Komponenten offen für Erweiterung aber geschlossen für Veränderung
- Polymorphie
- Erweiterung ohne Änderung des bestehenden Codes
- nur Abhängigkeiten von Abstraktionen nicht Implementierungen - 115Liskov Substitution Principle (LSP)Unterklassen erfüllen alle Verträge ihrer Oberklassen, überschriebene Methoden besitzen keine stärkeren Vorbedingungen und keine schwächeren Nachbedingungen
Unterklassen sollen nicht mehr erwarten und nicht weniger liefern als ihre Oberklassen - 116Interface Segregation Principle (ISP)"Many client specific interfaces are better than one general purpose interface"
Kategorisierung ähnlicher Klienten in Interfaces
Verwendung derselben Methode in mehreren Klienten-Typen -> Methode in allen Interfaces - 117Dependency Inversion Principle (DIP)keine Abhängigkeit zu konkreten Klassen sondern zu Interfaces
- 118Inversion of Control (IoC)Hollywood-Principle (Don't call us, we call you)
Kontrollfluss geht vom Framework aus (Framework ruft System auf nicht umgekehrt) - 119Dependency Injection (DI)Abhängigkeiten zu anderen Bausteinen explizit machen durch Methoden zur Übergabe von Referenzen
- gut modularisiert
- leicht verständlich
- einfach zu testen - 120Varianten von Dependency InjectionField Injection
Interface Injection
Setter Injection
Constructor Injection
Auflösung entweder explizit oder automatisch - 121Constructor InjectionKonstruktor erwartet benötigte Objekte
- 122Setter InjectionBereitstellung von Settern für benötigte Objekte
- 123Field Injectionbenötigte Objekte per Reflection direkt in Feld geschrieben
normalerweise per Annotation/Metadaten - 124Interface InjectionDefinition eines Interfaced für Kennzeichnung
abhängige Klasse Implementiert interface - 125Vor-/Nachteile von Dependency InjectionObjekt bekommt alles was es braucht
- Konfiguration zum Auflösen der Abhängigkeiten nötig
- mehrere Konfigurationen für unterschiedliche Zwecke
- Austausch einer Implementierung erfordert Konfigurationsänderung nicht eine Anpassung der konfigurierten Objekte
- Tests können Abhängikeiten durch Dummys/Mocks ersetzen
- Überblick über Abhängigkeiten behalten, manchmal schwer - 126Dependency Injection FrameworkSteuerung der Konfiguration
Zusätzliche Funktionen neben Konfiguration
- einheitlicher Mechanismus
- Lebenszyklen (singleton, prototype, request, session, conversation)
- Aspect Oriented Programming (AOP) durch Erweiterung der Objekte (Proxies, Weaving) (Transactions, Security, Caches) - 127Was gehört unter DI-Kontrolle?ja: Services, Factories Repositories
nein: Entities, ValueObjects, Aggregates - 128Logische Ebenen für Client/Server-VerteilungPräsentation (JSP/View)
Application Logic (Servlet/Controller, Service, Entity, Value)
Data Management + External Services (DB-Service, Fremdsystem) - 129Anforderungen an die technische Infrastrukturmöglichst einfaches Verteilungsmodell für Konstruktion von Oberfläche, Businesslogik, Persistenzschicht & Schnittstellen, damit geringe Komplexität, Produktivität, Testbarkeit erhalten bleibt und das System für Benutzer erwartungskonform und performant ist.
- 130Mögliche Client/Server-Schnitte
- 131Fat-ClientÜbertragung der Entities auf den Client gehört zum Benutzungsmodell
IDE, Textverarbeitung, explizite Kooperation
Einzelplatzsysteme mit DB Zugriff vom Client
Einzelplatzsysteme mit Remote-Aufruf von. CRUD-Operationen (auch per AJAX denkbar) - 132Rich-ClientTransparenter Transport der Entities auf den Client
Nachteile: große Entities nur teilweise laden (Performance), Trennung vom persistenten Kontext -> keine verteilten Transaktionen
Beispiel: Client/Server Anwendung mit Applikationslogik teilw. auf Client, Rich GUI (GWT,...), Mobile Apps - 133Thin-ClientOberfläche und fachliche Logik durch DTO über Netz versorgt
Nachteile: fehlende fachliche Konsistenz am Client, viele Anfragen am Service für Änderung der Entities
Beispiel: Client/Server Anwendung mit Rich GUI (GWT,...), Ajax-Anwendung als FE - 134Ultra-Light/Thin-ClientImplizite Kooperation mit Datenkonsistenz (Antrags-/Auftragsverarbeitung in Geschäftsprozessen)
DB + Fremdsysteme müssen nicht am selben Server wie Businesslogik laufen (weiterer Verteilungsschritt)
Beispiele: klassische Webanwendung (Server-side rendering), Half-Object-Lösungen - 135Dimensionen für Gestaltung von IT-ArbeitsplätzenUmfang der IT-Kenntnisse
Vielfalt der Aufgaben
Umfang der Unterstützung
Ausmaß an Flexibilität - 136Integration verteilter AnwendungenFunktionalität über mehrere Anwendungen verteilt
isolierte Applikation zur gemeinsamen Lösung verbinden - 137Ansätze für die IntegrationFile Transfer (Dateitransfer)
Shared Database (gemeinsame Datenbank)
Remote Procedure Invocation (verteilte Aufrufe)
Messaging (Nachrichten) - 138File TransferVoraussetzung: gemeinsames Dateisystem, Format, Exporter & Importer
Vorteile: einfach, alle Plattformen und Sprachen, asynchron, lose Kopplung, kaum Eingriffe für Export, App-Internas verborgen
Nachteile: Inkonsitenz bei großen Update-Intervallen, viel Absprache bei DEVs (Namings, Paths), Semantik lokal festgelegt, manueller Eingriff naheliegend - 139Shared DatabaseVoraussetzung: Aufsetzen der App auf einer Datenbank möglich, gemeinsames Datenschema
Vorteile: zeitgleiche Updates, Verbreitung von SQL/OR-Mappern, Datenbestand konsistent und synchron, Zwang guter Datenmodellierung
Nachteile: universelles DB-Schema schwierig, semantische Unterschiede zw. Apps, Performance-Issue der DB, Fremdsoftware hat eigene DB, ungekapselter Austausch, hohe Kopplung - 140Remote Procedure InvocationVoraussetzung: Veröffentlichung von nutzbaren Funktionen, gemeinsame Technologie, Berücksichtigung von Ausfällen
Vorteile: Wiederverwendbarkeit, lokale Kapselung, Integrität der eigenen Daten, weniger Code Duplication
Nachteile: Enge Kopplung, geringe Stabilität, Performance und Ausfallsicherheit, Änderung betreffen alle Nutzer, gegenseitige Aufrufe problematisch - 141MessagingVoraussetzung: Anschluss an Message BUS, Technologie
Vorteile: lose Kopplung, Ausfallsicherheit, Performance (Message-Queue), asynchron, Nachrichten können Daten oder Funktion triggern
Nachteile: Asynchronität muss beherrscht werden, semantische Dissonanz - 142Message-Oriented Middleware (MOM)Grundkonzepte: Send & Forget, Store & Forward
Lose Kopplung und Zuverlässigkeit:
Kanäle sind unabhängig von der Anwendung -> keine Standortabhängigkeit
Kanäle sind asnchron und verlässlich -> keine zeitliche Abhägigkeit
Datenaustausch in in sich geschlossenen Nachrichten -> keine Datenformatabhängigkeit - 143Auswirkungen asynchroner KomunikationParallelisierung -> schneller, schwieriger zu debuggen
Callback -> Empfang und Verarbeitung in neuem Kontext während anderer Arbeiten
unbestimmte Ausführungsreihenfolge -> unabhängige Prozesse mit Synchronisationslogik - 144Delivering im MOM- Queue auf dem Server
- Message kann nur einmal gelesen werden
- mehrere Producer/Consumer können selbe Queue verwenden -> Reihenfolge nicht sicher - 145Herausforderung durch MOM- komplexes Programmiermodell (eventgetrieben, Logik auf Handler verteilt, Debugging)
- Nachrichtenreihenfolge (Zustellgarantie, keine Reihenfolge, Resequenzierung)
- Synchrone Anwendungsszenarien (Anwender erwarten synchrone Bearbeitung, Anwendung muss sich entsprechend verhalten)
- Performanz (große Datenmengen besser außerhalb)
- Plattform Support (eingeschränkte Möglichkeiten)
- Herstellerabhängigkeiten (trotz Standards plattformunabhängig, Integration ist weitere Herausforderung) - 146Integration von Alt-/FremdsystemenGeschäftsprozesse über einzelne Systeme verteilt
Schnittstellen passen nicht zusammen
Unterschiedliche Abstraktiongrade
-> Integration über MOM - 147Probleme bei verteilten AnwendungenOverhead durch entfernte Aufrufe
erhöhte Komplexität
zusätzliche Datenkonvertierung und Transport
Fehlerbehandlung über Systemgrenzen
Anzahl Fehlerquellen steigt
Testaufwand steigt
Nebenläufigkeitsprobleme
Dateninkonsistenz bei/nach Ausfällen - 148Lösungen für verteilte SystemeVerteilung vermeidbar?
Entwurf stabiler Schnittstellen
höhere Serverlast statt höherer Datentransfer
Verarbeitungsprozesse nahe an den Daten - 149Probleme bei Integration bestehender Systeme (Legacy)monolithische Systeme
kein Quelltext/Dokumentation
ungenügende Fehler-/Ausnahmebehandlung
schlechte Datenqualität
anderes Laufzeitverhalten
übergreifende Transaktionen - 150Lösungen für Legacy-SystemeSchnittstellen und Verantwortlichkeiten klar definieren
minimal-invasive Eingriffe
Migration statt Integration
-> bei wenig Wissen zum Altsystem
-> bei größerem Integrationsrisiko als Geschäftswert - 151Warum gibt es Service-Oriented Architecture (SOA)?Ansprüche von Kunden und Partnern steigen (Marktdruck)
viele Geschäftsprozesse ausschließlich mit IT-Unterstützung
bestehende IT meist Monolithen, unflexibel und lange gewachsen
IT-Budgets oft für Entwicklung oder Modernisierung einzelner Anwendungen ohne Bezug zum gesamten Prozess
-> SOA für Flexibilität mit Wertschöpfung bei geänderten Bedingungen
-> Technik ist Mittel zum Zweck - 152Was ist SOA?IT-Architektur mit Services als zentralem Element, Services realisieren Geschäftsfunktionen
-> integrierbare Einheiten (lose gekoppelt, selbstständig betriebene, verwaltete und gepflegte Software, kapseln Funktion über Schnittstelle)
-> Service-Vertrag für Schnittstelle inkl. Metadaten
-> Nutzung über entfernte Aufrufe mit offenen Standards (XML, JSON, ...) - 153Wie funktioniert SOA?Service Provider meldet Schnittstelle and Service Verzeichnis
Service Consumer fragt Service Verzeichnis nach Service für Schnittstelle
Service Consumer ruft Service Provider auf - 154Kopplung zwischen Serviceszeitliche Abhängigkeit: synchron (beide Services müssen zeitgleich aktiv sein
örtliche Abhängigkeit: Adresse des aufgerufenen Service darf sich nicht ändern
Struktur- und Implementierungsabhängigkeit: direkte Nutzung der Implementierung statt der öffentlichen Schnittstelle (Austauschbarkeit)
Datenabhängigkeit: Nutzung einer Datenstruktur des anderen Service - 155Peer-to-Peergleichberechtigte über Netzwerk verbundene Komponenten
zeitgleich Client & Server
Einsatzzweck: ausfallsichere Datenverteilung
+: hohe Ausfallsicherheit, geteilte Ressourcen (CPU, RAM, ...)
-: Auffinden bei großen Netzen schwierig, Fehlerbehandlung - 156Blackboardohne Algorithmus
Ableitung der Lösung aus dem Blackboard
Quellen tragen gemeinsam zur Lösung bei
parallele Erarbeitung und Bewertung von Alternativen
+: effizient für große Datenmengen, zentrales Management, einfach für neue Quellen, Quellen arbeiten parallel
-: Einigung aug ein Datenmodell, effiziente Verteilung schwer, Verarbeitungsende schwer festzulegen, Herausforderung Debuggen und Testen - 157Technische ArchitekturPersistenz
Kommunikation & Nebenläufigkeit
grafische Oberflächen
Internationalisierung
Sicherheit
Logging/Protokollierung
Fehlerbehandlung
Energieeffizienz
-> systemübergreifende Wiederverwendbarkeit
-> wechselseitige Abhängigkeit - 158Paradigmen von Datenbankenhierarchische DB: jeder Datensatz hat einen Vorgänger (außer Wurzel)
NetzwerkDB: m:n Beziehungen zw. Datensätzen
relationale DB (Tupel/Spalten): Tabellen, Schlüsselbeziehung, SQL, verbreitet, zuverlässig
objektorientierte DB: Objekte und Graphen direkt gespeichert, einfaches Programmiermodell, wenig verbreitet, gute Performance/Robustheit
GraphDB: flexible aber komplex, endliche Beziehungen
Key-Value-DB: flexibel, skalierbar, hoch performant, assoziative Datenfelder
dokumentenorientierte DB: performant, wenn typische Abfragen entspricht, Dokumente im Standardformat (JSON, XML, ...), Dokumente über Schlüssel adressierbar oder per API über Inhalt zu finden - 159Risiken und Probleme der PersistenzAbhängigkeiten zu technischen Details
Seiteneffekte durch Trigger
Strukturbruch zw. Programmiersprache und Datenbank oder anderen Systemen
große Unternehmen speichern in Mainframesysteme -> Interaktion mit dem System erzeugt Komplexität - 160Lösungsmuster der PersistenzEntkopplung des fachlichen Kerns von der Persistenz durch eigene Schicht
zwei Subschichten: Objektschicht (Kapselung der Objektorientierung) & Speicherungsschicht (Schnittstelle zur DB) - 161Anforderungen an PersistenzschichtUnterstützung mehrerer Mechanismen
parallele Verbindungen
automatische Erzeugung von eindeutigen IDs
Transaktionen
Lazy-Loading
Kapselung durch Schnittstellen für save, read, delete & dirty-Flag, Factories
Performance-Tuning ohne Code-Anpassung - 162Kommunikation und NebenläufigkeitKommunikationsstile: Remote Procedure Call (RPC), Publish-Subscribe, Broadcast
Zusammenführung der Ergebnisse bei Nebenläufigkeit - 163grafische OberflächenFragestellungen: Wie werden Daten präsentiert?, Wie interagiert der Benutzer?, Wer steuert die Navigation?, Wer kontrolliert Zustandswechsel?, Wer verarbeitet Ergebnisse?, Welche fachliche Komponente stellt Inhalte bereit?
Interaktionsstile: objektorientiert, Frage-Antwort (Masken, Wizards), formularbasiert, Menüs und Fenster - 164Probleme der Internationalisierungmehr Dimensionen als nur Sprache: Zeichen/Schriftsätze/Layout, ltr vs. rtl, Zeitzonen, Formatierung, Währung, Adressen, Namen, Tastenkürzel, Datenbezeichnungen, politische/kulturelle Aspekte, abweichende Informationsarchitektur, ...
- 165Lösungen für Internationalisierungexterne Ressourcen für Sprachelemente, dynamisches GUI-Layout, Sprachauswahl durch Nutzer/OS/Profil, Zeichensätze mit ausliefern, Datenmodell um Sprache/Länder ergänzen, Bibliotheken für Formatierung, Währungswechsel beachten & Referenzwährung festlegen, Zeitzone durch Timestamp Service abdecken, Verzicht auf Symbole & Metaphern bei heterogenen Zielgruppen
- 166SicherheitMechanismen zur Gewährleistung von Datensicherheit, Datenschutz und Missbrauchsverhinderung
Sicherheitsziele: Vertraulichkeit, Integrität, Authentizität, Autorisierung & Verfügbarkeit - 167Probleme der SicherheitKommunikation zw. Systemen über Firewall
Public-Key-Infrastructure zur Erzeugung und Verwaltung von Schlüsseln und Zertifikaten
zusätzliche Hardware möglich
Performance-Verlust
gesetzliche Rahmenbedingungen - 168Lösungen für Sicherheitkryptographische Verfahren auf Unkenntnis der Schlüssel nicht des Verfahrens -> nicht selbst entwickeln
eigene Zertifizierungstelle vs. gekaufte Dienstleistung
Sicherung auf niedriger OSI-Ebene
Sicherheitsanforderungen bei Auswahl von Verteilungsplattform berücksichtigen
Verbindungspooling für Performance - 169Probleme der ProtokollierungAbhängigkeit vermeiden
hohe Flexibilität notwendig (Was?, Kategorie?, Kanäle?, Format?)
OS und Programmiersprachengrenzen (Komplexe Zusammenführung, getrenntes Log erschwert Konsolidierung) - 170Lösungen für ProtokollierungFramework und Fassade nutzen
Weg den Nutzers verfolgbar machen
Interaktion mit anderen Systemen protokollieren
Ringpuffer für Platzprobleme
Aspektoriente Programmierung nutzen - 171Ausnahme- und FehlerbehandlungFehler: Unterschied zw. erwartetem und konkretem Ergebnis/Zustand
Ausnahme: Baustein kann aufgrund eines Fehlers nicht normal ablaufen
Anforderungen:
angemessene Reaktion des Systems
Verhinderung von Seiteneffekten
leichte Fehlerdiagnose
Unterscheidung von Original- und Folgefehler
vorzeitige Erkennung und Prävention - 172Fehlerkategorienfachlicher Fehler
technischer Fehler
Syntaxfehler
Format-/Semantikfehler
Protokollfehler
korrigierbare Fehler
nicht korrigierbare Fehler
-> mit QS-Experte festlegen, semantische Lücken in Schnittstellen, Schnittstellen von Fremdsystemen - 173Muster zur FehlerbehandlungAbsprache mit externen Systemen
technische Fehler verbergen (Logging, Benutzerfreundliche Meldungen
Fail Fast (Folgefehler vermeiden)
Protokollierung nur an einer Stelle
keine leeren Catch-Blöcke oder Umwandeln von Exceptions - 174Energieeffizienzunangemessener Energieverbrauch
-> angemessener Scope & Architektur
Vermeidung unnötiger Aktionen/ Berechnungen
-> effiziente Algorithmen & Caching
-> schlanke Assets
-> kompiliert statt interpretiert
-> optimiertes Cloud-RZ statt on-premise
-> Burstable instances
-> ARM erfordert extra Builds
-> Sizing der Instanzen
-> "grüne" Server
-> Auslastungsmonitoring - 175Warum Architektur dokumentieren?Kommunikation
Erklären
Bewertung
Überblick wahren
Quelltext zu geringe Abstraktion - 176Ziele der ArchitekturdokumentationUnterstützung des Entwurfs
Überblick über längeren Zeitraum
Leitung der Umsetzung
-> Fehler und Probleme beseitigen
-> geänderte Anforderungen erfüllen
-> Reaktion auf geändertes technisches Umfeld
Nachvollziehbarkeit und Bewertung - 177stakeholder gerechte BeschreibungJeder benötigt seinen eigenen Plan (Abstraktion)
Überschneidung möglich (Konsistenz) - 178ArchitektursichtenSystem aus spezifischer Perspektive
viele Sichten mit unterschiedlichem Schwerpunkt
Sichten richten sich an Adressaten
Spezialisierung -> Handhabung der Komplexität
Informationen können mehrfach auftreten
Konsistenz -> kein Widerspruch
Art der Sicht und deren Benennung ansichts-/kontextabhängig - 179Arten von ArchitektursichtenKontextsicht
Verteilungssicht
Bausteinsicht
Laufzeitsicht
zusätzlich:
Datensicht
fachliche Sicht - 180KontextsichtSystem als Black-Box (Sicht von außen)
externe Akteure
Schnittstellen zur Außenwelt (Art, Protokoll, Muster)
wichtigste Anwendungsfälle
-> Einstiegspunkt - 181BausteinsichtSoftware-/Implementierungskomponenten (Abstraktion vom Quellcode)
statischer Aspekt (Zerlegung, Beziehungen) Bausteine und deren Abhängigkeiten
Was muss implementiert, konfiguriert, gekauft werden?
-> Unterstützung Projektmanagement (Arbeitspakete)
-> Unterstützung Entwickler (Big Picture) - 182VerteilungssichtVerteilung Laufzeitelement zu Hardware
logische Kanäle zu physische Kanäle
technische Komponenten und deren Verfügbarkeit
Netz- und Speicherkapazitäten
Was wird wo installiert?
-> Kommunikation mit Betrieb
-> Konfiguration und Administration
-> Engpässe, Kosten, Risiken - 183LaufzeitsichtWelcher Baustein Teil welches Use Cases?
Zusammenarbeit/Interaktion von Komponenten/externen Systemen?
Wie startet/beendet das System?
Instanzen und Lebenszyklen von Bausteinen
-> Unterstützung Entwickler
-> Kommunikation Betrieb - 184Diagramm-/Dokumentarten für Sichten
- 185PaketdiagrammGruppiert Modellelemente auf verschiedenen Abstraktionebenen zur Komplexitätsreduktion
- 186Komponentendiagrammzeigt interne und externe Sicht von Komponenten, sowie die Verknüpfung von Komponenten untereinander
- 187Zeit(verlaufs)diagrammZeigt Zustandsänderungen der Interaktionspartner aufgrund von Zeitereignissen und Nachrichten
- 188AktivitätsdiagrammDient zur Modellierung von prozeduralen Abläufen in Form von Kontroll- und Datenflüssen. Besonders sinnvoll für die Darstellung von konfigurierbaren und nebenläufigen Abläufen
- 189VerteilungsdiagrammZeigt die eingesetzte Hard- und Software-Topologie in Form von Knoten und Kommunikationsbeziehungen sowie das zugeordnete Laufzeitsystem in Form von Artefakten
- 190KompositionsstrukturdiagrammZeigt die interne Struktur von Modellelementen und ermöglicht dadurch eine hierarchische Dekomposition
- 191KommunikationsdiagrammBeschreibt einfache Interaktionen
Fokus: strukturelle Beziehungen - 192InteraktionsübersichtsdiagrammZeigt auf abstrakter Ebene den Kontrollfluss zwischen verschiedenen Interaktionsabläufen
- 193Use-Case-DiagrammGraphische Sicht auf einen oder alle Akteure, Use Cases und ihre Interaktion im Zusammenhang mit einem System
- 194IT-LandschaftWelche Systeme werden in welchen Versionen betrieben?
Über welche Schnittstellen wird zusammengearbeitet?
Wo gibt es Verbesserungspotential? - 195GlossarIst-Analyse: Erschließung von Fachsprache, relevante Begriffe in Prosa definieren, Unterschiede im Gebrauch festhalten
Soll-Konzept: Rekonstruktion von Fachsprache, Vereinheitlichung der Fachbegriffe, neue Begriffsbildung - 196Szenarien & Visionenerzählende Prosatexte (Fragen stellen und Begriffe klären)
Szenarien auf Ist-Ebene (Arbeitskontexte/-prozesse bekannter Akteure, Generalisierung für Rollen)
Szenarien auf Soll-Ebene (Vision über System im Einsatzkontext)
Szenarien im offenen Design (Vision über Systemeinsatz mit vorgestellten Akteuren, typische oder extreme (+/-) Situationen, Kreativität im Design) - 197Leitfragen für EntscheidungenArchitecture Decision Records
Textstruktur
Datei mit 5 Infos:
- Titel
- Kontext
- Entscheidung
- Status
- Auswirkung
- 198SchnittstellendokumentationBedarf für Schnittstellendokumentation obwohl in Sichten enthalten
- Identifikation
- bereitgestellte Ressourcen
- Fehlerszenarien
- Variabilität/Konfigurierbarkeit
- Qualitätseigenschaften
- Entwurfsentscheidungen
- Benutzungshinweise - 199ARC42
- 200typische Architekturdokumentezentrale Architekturbeschreibung
Architekturüberblick
Dokumentationsübersicht
Übersichtspräsentation
Architekturtapete
Handbuch zur Architekturdokumentation
technische Informationen zum Entwicklungsprozess
Information
- Description
- Foundation Level iSAQB Flashcards on iSAQB Foundation Level Inhalte, created by Lukas Holzner on 07/03/2024.
- Created by
- Lukas Holzner
- Views
- 33
- Tags
- Rating