39273752
Description
Flashcards by Lukas Holzner, updated 10 days ago
|
Created by Lukas Holzner
about 2 months ago
|
|
| Question | Answer |
| softwareintensives System | Menge von Bausteinen vollständig oder wesentliche Teile sind Software essentielle Aufgaben zur Erfüllung des Zwecks |
| Rolle der Softwarearchitektur | grobes Konzept systemweite Abstraktion Struktur der Strukturen Wiederverwendung abstrakter Ideen |
| Vorteile der Softwarearchitektur | langfristige Planung verständlich analysierbar wiederverwendbar |
| Arten von Architektur | Geschäftsarchitektur Prozessarchitektur Integrationsarchitektur Anwendungsarchitektur Infrastrukturarchitektur |
| Inhalte der Geschäftsarchitektur | Strategie Produkte Dienstleistungen |
| Inhalte der Prozessarchitektur | Geschäftsprozesse Organisationseinheiten Rollen |
| Inhalt der Integrationsarchitektur | Bebauungsplan fachliche Services Integration |
| Inhalt der Anwendungsarchitektur | Modularisierung Wiederverwendung Schnittstellen |
| Inhalt der Infrastrukturarchitektur | Server Plattformen Netzwerkkomponenten |
| Definition: Softwarearchitektur | grundlegende 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 |
| Rolle von Software-Architektur im Entwicklungsprozess | Projektleitung/-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 |
| Nutzen von Software-Architektur | Brü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 |
| Definition: Baustein | Abstraktion von speziellen Programmierkonstrukten oder Beschreibungselementen |
| Arten von Bausteinen | Pakete, Packages, Namespaces Klasse, Modul, Funktion, Prozedur Komponente, Programm Skript Bibliothek, Framework Datenstruktur, DB-Tabelle Layout-/Mappingdefinition |
| Aspekte von Bausteinen | Export und Import von Schnittstellen (Contract) Kapselung & Austauschbarkeit Konfiguration & hierarchische (De-)Komposition (Subbausteine) |
| Arten von Sichten | Blackbox Whitebox Greybox |
| Blackbox-Sicht (Außensicht) | nur Schnittstellen mit Funktionalität (Dienste) kein Innenleben (Geheimnisprinzip) Sicht des Architekten |
| Whitebox-Sicht (Glasbox-/Innensicht) | innere Struktur und Zerlegung in Subbausteine Arbeitsweise der Subbausteine und Delegation der Schnittstellen an das Innenleben Sicht des Implementierers |
| Greybox-Sicht (Konfigurationssicht) | Ausschnitt der inneren Struktur (Konfiguration, Parameter, Varianten) |
| Verantwortung des Architekten bei Blackbox-Bausteinen | Erfüllung von funktionalen und nicht-funktionalen Anforderungen Methodensignaturen und Datenformate der Schnittstelle Ausmaß der Kopplung mit anderen Bausteinen |
| Verantwortung des Architekten bei Whitebox-Zerlegung | Enthaltene Blackbox-Bausteine Begründung der Zerlegung Abhängigkeiten & Testbarkeit der enthaltenen Blackbox-Bausteine |
| Definition: Schnittstelle | wohldefinierter 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) |
| Postel's Law | Sei strikt bei dem, was du tust, und nachsichtig bei dem, was du von anderen akzeptierst. |
| Orte der Schnittstellendefinition | |
| Ziele von Software-Architekturen | Langlebigkeit Wartbarkeit Änderbarkeit/Erweiterbarkeit Energieeffizienz Qualitätsmerkmale (oben) als Differenzierung ggü. Funktionalität |
| Aufgaben des Software-Architekten | konstruieren und entwerfen absichern der Erfüllung der Anforderungen beraten dokumentieren vereinfachen kommunizieren bewerten Diplomatie und Akrobatik Mut (nicht waghalsig) |
| Abwägungen | Komplexität <--> Einfachheit Kosten & Termine <--> Leistung neue Tech. <--> etablierte Tech. min. Schnittstellen <--> enge Integration strikte Kontrolle <--> agile Entscheidungen Top-Down <--> Bottom-Up |
| angrenzende Rollen an den Software-Architekten | Auftraggeber Projektleiter Anwender Entwickler Qualitätsmanager Architecture-Board Businessanalyst Sicherheitsexperte Betrieb |
| Informationen sammeln | Materialien 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) |
| Fragen zu Lösungsidee | Was 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) |
| Was 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 |
| Wie 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 |
| Wer 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? |
| Welche Schnittstellen gibt es? | externe Systeme (Export/Import) Stabilität/Fehlertoleranz Funktionen oder Daten Semantik Synchronität Performance Änderbarkeit der anderen Seite |
| Wie 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 |
| Wie 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 |
| Systemidee kommunizieren | Abstimmung mit Auftraggebern und Projektleitung Kommunikation zu allen Beteiligten Indikator für Risiken falls Beschreibung von Aspekten ungenau |
| Einflussfaktoren und Randbedingungen klären | |
| typische Risiken | enger 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) |
| Risiken identifizieren | keinen 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) |
| Qualitätseigenschaften | Funktionalität Zuverlässigkeit Benutzbarkeit Effizienz Sicherheit Kompatibilität Wartbarkeit Portierbarkeit |
| Qualitätsmerkmale der Eigenschaft Funktionalität | Eignung Verwendbarkeit Genauigkeit Interoperabilität |
| Qualitätsmerkmale der Eigenschaft Zuverlässigkeit | Reife Fehlertoleranz Ausfallsicherheit Datensicherheit |
| Qualitätsmerkmale der Eigenschaft Benutzbarkeit | Verständlichkeit Erlernbarkeit Bedienbarkeit Attraktivität |
| Qualitätsmerkmale der Eigenschaft Effizienz | Zeitverhalten Ressourcennutzung |
| Qualitätsmerkmale der Eigenschaft Sicherheit | Integrität Vertraulichkeit Nachweisbarkeit Authentizität Verantwortlichkeit |
| Qualitätsmerkmale der Eigenschaft Kompatibilität | Austauschbarkeit Interoperabilität Compliance |
| Qualitätsmerkmale der Eigenschaft Wartbarkeit | Analysierbarkeit Änderbarkeit Erweiterbarkeit Stabilität Testbarkeit |
| Qualitätsmerkmale der Eigenschaft Portierbarkeit | Anpassbarkeit Installierbarkeit Ersetzbarkeit Konfigurierbarkeit |
| Produktkarton mit Beipackzettel | Wie 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? |
| Top-Down-Entwurf | Zerlegung in Teilprobleme (Dekomposition) Vision des Gesamtsystems |
| Bottom-Up-Entwurf | Zusammenbau von Teillösungen (Komposition) fachliche Klassen und Teilfunktionen |
| Vorteile Top-Down-Entwurf | gutes Problemverständnis maschinen- und sprachunabhängig kein sich-im-Detail-verlieren saubere Schnittstellen/Konsistenz Entwurf im Produkt erkennbar |
| Nachteile Top-Down-Entwurf | kritische Integration am Ende Übersehen von existierenden (Teil-)Lösungen gravierende Änderungen bei spät erkannten Problemen spätes Feedback über Richtigkeit |
| Vorteile Bottom-Up-Entwurf | hoher Wiederverwendungsgrad hohe Funktionssicherheit durch inkrementelle Tests schrittweise Integration Beginn mit vermuteten Teilproblemen |
| Nachteile Bottom-Up-Entwurf | potentiell nicht alles benötigt Orientierung an technischen Gegebenheiten statt Benutzeranforderung Gefahr der frühzeitigen Optimierung Wildwuchs |
| Architekturebenen | fachliche Architektur Architekturstile technische Infrastuktur technische Architektur auf allen Ebenen: Programmdesign |
| fachliche Umgangsformen | Art 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) |
| Entwurf nach Zuständigkeiten | Modularität Separation of Concerns Kohäsion Single Responsibility Principle Law of Demeter |
| Entwurfsprinzipien | große Bausteine vermeiden Don't Repeat Yourself (DRY) Keep It Simple, Stupid! (KISS) Schnittstellen verbergen Interna (Geheimnisprinzip): Kapselung & Lokalität |
| Law of Demeter | "If you delegate, delegate fully!" "Don't talk to a stranger!" Fluent Interface |
| Ziele von gutem Design | geringe Kopplung Zyklenfreiheit |
| Kopplung | Maß der Abhängigkeit eines Bausteins von der Umgebung Vorteile bei geringer Kopplung: leichte Anpassbarkeit Verständlichkeit gute Testbarkeit hohe Wiederverwendbarkeit |
| Zyklenfreiheit | Acyclic Dependency Principle (ADP) Auswirkung auf: Wartbarkeit Austauschbarkeit Testbarkeit Einstiegspunkt beim Analysieren |
| fachliche Architekturansätze | Transaction Script Table Module Domain Model |
| Transaction Script | gut 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 |
| Table Module | Klasse 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 |
| Domain Model | typische 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 |
| CRC-Karten | Klassen/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) |
| Vorgehen bei CRC-Karten-Modellierung | Fachbegriffe aus Use Cases und Glossaren Was tun Akteuere mit den Dingen? Rollenspiel um Lücken zu finden bei der Nachstellung der Use Cases |
| Vermeiden bei CRC-Karten-Modellierung | Klassen 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 |
| Architekturstil | prinzipielle Lösungsstruktur, die durchgängig und weitgehendem Verzicht auf Ausnahmen angewandt werden sollte Microservice Schichtenarchitektur Mustersprache |
| Schichtung | Standardschichten: 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 |
| Vorteile von Schichtung | Flexibilität Unabhägigkeit Austauschbarkeit minimierte Abhängigkeiten leicht verständlich |
| Nachteile von Schichtung | negativer Einfluss auf Performance (Gegenmaßnahme: Layer-Bridging) manche Änderung schlecht unterstützt (Anpassung in vielen Schichten) |
| Schwierigkeiten & Lösungen für die Infrastrukturschicht | enthält Logging Framework, Libraries, OR-Mapper, ... Zugriffe aus allen Schichten notwendig Umwandlung in fachliches Modul (Libraries/Framework nur auf entsprechender technischer Schicht) |
| Effekte durch Zwang zur Zyklenfreiheit | Build-System verbietet Zyklen Monolith mit vielen Satelliten Pipes & Filter für Datenfluss (Trennung fachlicher und technischer Bestandteile) |
| Trennung fachlicher und technischer Bestandteile | jeder 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 |
| Architekturen die Fachlichkeir und Technik trennen | Hexagonale Architektur (Adapter verbinden technische Schnittstellen mit fachlichem Anwendungskern) Onion / Clean Architecture Domain Driven Design |
| Elemente der Domain-Schicht | |
| DDD Entities | Kernobjekte Zustand anhand von ValueObjects Konsistenz des Zustands unveränderliche Identität klar definierter Lebenszyklus (immer) persistent anwendungsfachlich |
| DDD ValueObjects | keine eigene Identität beschreiben Zustand anderer Objekte unveränderlich können aus anderen ValueObjects bestehen, nie aus Entities anwendungsfachlich |
| DDD Services | stellen 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 |
| DDD Factories | Erzeugung von Aggregates, Entities und ValueObjects innerhalb der Domäne kein Zugriff auf technische Bausteine anwendungsfachlich |
| DDD Repositories | kapseln technische Details der Infrastukturschicht ggü. der Domänenschicht beschaffen Objektreferenzen von Entities, die ais DB gelesen werden müssen Transformationssoftware |
| DDD Aggregates | vernetze Entities & ValueObjects einzige Entity als Wurzel Änderung als Einheit fachliche Konsistenz und Integrität anwendungsfachlich |
| DDD Schichtenarchitektur | UI: 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 |
| Werkezug-Material-Ansatz | Erweiterung 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 |
| Conway'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 |
| Zuordnung Bausteine zu Teams | Komponenten-Teams: Wenn ein Team mehrere Bausteine umsetzt, werden diese verschmelzen Feature-Teams: Bausteine aus mehreren Schichten werden verschmelzen |
| Monolith vs. Microservices | Monolith: 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 |
| Entwurfsmuster | wiederkehrende Probleme und bewährte Lösungen standardisierte Arrangements von Bausteinen lokale Anwendung mehrere pro System |
| Ziele von Entwurfsmustern | Kopplung bei Erzeugung aufheben (Factory) Schnittstellenanpassung (Adapter, Bridge, Fassade) Kapselung (Proxy) dynamische und transparente Erweiterung (Decorator) Benachrichtigung ohne Addresat zu kennen (Observer) |
| Factory-Pattern | Schnittstelle zum Erzeugen von Objekten - System unabhängig von Objekten (Bibliothek, Framework) - Systemkonfiguration mit Produktfamilie - Wahrung der Konsistenz bei verwandten Produkten - Blackbox-Bibliothek |
| Vor-/Nachteile des Factory-Pattern | einfacher Austausch der konkreten & abstrakten Fabriken Anwendung nur einer Produktfamilie sichergestellt Erweiterung komplex, da Schnittstellen in allen Subklassen ergänzt werden müssen |
| Adapter-Pattern | Anpassung 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 |
| Klassenadapter | Anpassung an genau eine Zielklasse (keine Unterklassen) Verhalten adaptierter Klasse kann geändert werden nur ein Objekt, keine Durchreicheoperationen |
| Objektadapter | Adapter kann adaptierte und Subklassen anpassen begrenzte Verhaltensänderung ohne Unterklassenbildung |
| Brückenmuster | Entkopple 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 |
| Vor-/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 |
| Fassadenmuster | - Anbieten einer einfachen Schnittstelle zu komplexem Subsystem - einfache Sicht auf ein Subsystem für Klienten - Aufteilung eines Systems in Schichten mit definierten Eintrittspunkten |
| Vor-/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 |
| Proxymuster | Zugriffskontrolle ü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) |
| Vor-/Nachteile des Proxymusters | Ebene 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 |
| Dekorierermuster (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) |
| Vor-/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 |
| Beobachtermuster (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 |
| M(odel)-V(iew)-C(ontroller) Muster | Model: 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 |
| Broker (Vermittler)-Muster | Strukturierung 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) |
| Vorteile 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 |
| Nachteile Brokermuster | - eingeschränkte Effizienz - hohe Netzwerklast - niedrige Fehlertoleranz - schwieriges Testen/Debuggen - Interoperabilität zw. Brokern nicht erreicht - Wiederverwendung meist nur innerhalb des Servers |
| SOLID | S ingle Responsibility Principle O pen Closed Principle L iskov Substitution Pronciple I nterface Segregation Principle D ependency Inversion Principle |
| Single Responsibility Principle (SRP) | Jede Klasse nur eine fest definierte Aufgabe |
| Open/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 |
| Liskov 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 |
| Interface 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 |
| Dependency Inversion Principle (DIP) | keine Abhängigkeit zu konkreten Klassen sondern zu Interfaces |
| Inversion of Control (IoC) | Hollywood-Principle (Don't call us, we call you) Kontrollfluss geht vom Framework aus (Framework ruft System auf nicht umgekehrt) |
| Dependency Injection (DI) | Abhängigkeiten zu anderen Bausteinen explizit machen durch Methoden zur Übergabe von Referenzen - gut modularisiert - leicht verständlich - einfach zu testen |
| Varianten von Dependency Injection | Field Injection Interface Injection Setter Injection Constructor Injection Auflösung entweder explizit oder automatisch |
| Constructor Injection | Konstruktor erwartet benötigte Objekte |
| Setter Injection | Bereitstellung von Settern für benötigte Objekte |
| Field Injection | benötigte Objekte per Reflection direkt in Feld geschrieben normalerweise per Annotation/Metadaten |
| Interface Injection | Definition eines Interfaced für Kennzeichnung abhängige Klasse Implementiert interface |
| Vor-/Nachteile von Dependency Injection | Objekt 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 |
| Dependency Injection Framework | Steuerung 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) |
| Was gehört unter DI-Kontrolle? | ja: Services, Factories Repositories nein: Entities, ValueObjects, Aggregates |
| Logische Ebenen für Client/Server-Verteilung | Präsentation (JSP/View) Application Logic (Servlet/Controller, Service, Entity, Value) Data Management + External Services (DB-Service, Fremdsystem) |
| Anforderungen an die technische Infrastruktur | mö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. |
| Mögliche Client/Server-Schnitte | |
| Fat-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) |
| Rich-Client | Transparenter 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 |
| Thin-Client | Oberflä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 |
| Ultra-Light/Thin-Client | Implizite 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 |
| Dimensionen für Gestaltung von IT-Arbeitsplätzen | Umfang der IT-Kenntnisse Vielfalt der Aufgaben Umfang der Unterstützung Ausmaß an Flexibilität |
| Integration verteilter Anwendungen | Funktionalität über mehrere Anwendungen verteilt isolierte Applikation zur gemeinsamen Lösung verbinden |
| Ansätze für die Integration | File Transfer (Dateitransfer) Shared Database (gemeinsame Datenbank) Remote Procedure Invocation (verteilte Aufrufe) Messaging (Nachrichten) |
| File Transfer | Voraussetzung: 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 |
| Shared Database | Voraussetzung: 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 |
| Remote Procedure Invocation | Voraussetzung: 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 |
| Messaging | Voraussetzung: 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 |
| Message-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 |
| Auswirkungen asynchroner Komunikation | Parallelisierung -> schneller, schwieriger zu debuggen Callback -> Empfang und Verarbeitung in neuem Kontext während anderer Arbeiten unbestimmte Ausführungsreihenfolge -> unabhängige Prozesse mit Synchronisationslogik |
| Delivering im MOM | - Queue auf dem Server - Message kann nur einmal gelesen werden - mehrere Producer/Consumer können selbe Queue verwenden -> Reihenfolge nicht sicher |
| Herausforderung 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) |
| Integration von Alt-/Fremdsystemen | Geschäftsprozesse über einzelne Systeme verteilt Schnittstellen passen nicht zusammen Unterschiedliche Abstraktiongrade -> Integration über MOM |
| Probleme bei verteilten Anwendungen | Overhead 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 |
| Lösungen für verteilte Systeme | Verteilung vermeidbar? Entwurf stabiler Schnittstellen höhere Serverlast statt höherer Datentransfer Verarbeitungsprozesse nahe an den Daten |
| Probleme bei Integration bestehender Systeme (Legacy) | monolithische Systeme kein Quelltext/Dokumentation ungenügende Fehler-/Ausnahmebehandlung schlechte Datenqualität anderes Laufzeitverhalten übergreifende Transaktionen |
| Lösungen für Legacy-Systeme | Schnittstellen und Verantwortlichkeiten klar definieren minimal-invasive Eingriffe Migration statt Integration -> bei wenig Wissen zum Altsystem -> bei größerem Integrationsrisiko als Geschäftswert |
| Warum 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 |
| Was 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, ...) |
| Wie 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 |
| Kopplung zwischen Services | zeitliche 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 |
| Peer-to-Peer | gleichberechtigte über Netzwerk verbundene Komponenten zeitgleich Client & Server Einsatzzweck: ausfallsichere Datenverteilung +: hohe Ausfallsicherheit, geteilte Ressourcen (CPU, RAM, ...) -: Auffinden bei großen Netzen schwierig, Fehlerbehandlung |
| Blackboard | ohne 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 |
| Technische Architektur | Persistenz Kommunikation & Nebenläufigkeit grafische Oberflächen Internationalisierung Sicherheit Logging/Protokollierung Fehlerbehandlung Energieeffizienz -> systemübergreifende Wiederverwendbarkeit -> wechselseitige Abhängigkeit |
| Paradigmen von Datenbanken | hierarchische 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 |
| Risiken und Probleme der Persistenz | Abhä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 |
| Lösungsmuster der Persistenz | Entkopplung des fachlichen Kerns von der Persistenz durch eigene Schicht zwei Subschichten: Objektschicht (Kapselung der Objektorientierung) & Speicherungsschicht (Schnittstelle zur DB) |
| Anforderungen an Persistenzschicht | Unterstü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 |
| Kommunikation und Nebenläufigkeit | Kommunikationsstile: Remote Procedure Call (RPC), Publish-Subscribe, Broadcast Zusammenführung der Ergebnisse bei Nebenläufigkeit |
| grafische Oberflächen | Fragestellungen: 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 |
| Probleme der Internationalisierung | mehr 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, ... |
| Lösungen für Internationalisierung | externe 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 |
| Sicherheit | Mechanismen zur Gewährleistung von Datensicherheit, Datenschutz und Missbrauchsverhinderung Sicherheitsziele: Vertraulichkeit, Integrität, Authentizität, Autorisierung & Verfügbarkeit |
| Probleme der Sicherheit | Kommunikation 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 |
| Lösungen für Sicherheit | kryptographische 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 |
| Probleme der Protokollierung | Abhängigkeit vermeiden hohe Flexibilität notwendig (Was?, Kategorie?, Kanäle?, Format?) OS und Programmiersprachengrenzen (Komplexe Zusammenführung, getrenntes Log erschwert Konsolidierung) |
| Lösungen für Protokollierung | Framework und Fassade nutzen Weg den Nutzers verfolgbar machen Interaktion mit anderen Systemen protokollieren Ringpuffer für Platzprobleme Aspektoriente Programmierung nutzen |
| Ausnahme- und Fehlerbehandlung | Fehler: 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 |
| Fehlerkategorien | fachlicher Fehler technischer Fehler Syntaxfehler Format-/Semantikfehler Protokollfehler korrigierbare Fehler nicht korrigierbare Fehler -> mit QS-Experte festlegen, semantische Lücken in Schnittstellen, Schnittstellen von Fremdsystemen |
| Muster zur Fehlerbehandlung | Absprache 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 |
| Energieeffizienz | unangemessener 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 |
| Warum Architektur dokumentieren? | Kommunikation Erklären Bewertung Überblick wahren Quelltext zu geringe Abstraktion |
| Ziele der Architekturdokumentation | Unterstü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 |
| stakeholder gerechte Beschreibung | Jeder benötigt seinen eigenen Plan (Abstraktion) Überschneidung möglich (Konsistenz) |
| Architektursichten | System 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 |
| Arten von Architektursichten | Kontextsicht Verteilungssicht Bausteinsicht Laufzeitsicht zusätzlich: Datensicht fachliche Sicht |
| Kontextsicht | System als Black-Box (Sicht von außen) externe Akteure Schnittstellen zur Außenwelt (Art, Protokoll, Muster) wichtigste Anwendungsfälle -> Einstiegspunkt |
| Bausteinsicht | Software-/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) |
| Verteilungssicht | Verteilung 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 |
| Laufzeitsicht | Welcher 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 |
| Diagramm-/Dokumentarten für Sichten | |
| Paketdiagramm | Gruppiert Modellelemente auf verschiedenen Abstraktionebenen zur Komplexitätsreduktion |
| Komponentendiagramm | zeigt interne und externe Sicht von Komponenten, sowie die Verknüpfung von Komponenten untereinander |
| Zeit(verlaufs)diagramm | Zeigt Zustandsänderungen der Interaktionspartner aufgrund von Zeitereignissen und Nachrichten |
| Aktivitätsdiagramm | Dient 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 |
| Verteilungsdiagramm | Zeigt die eingesetzte Hard- und Software-Topologie in Form von Knoten und Kommunikationsbeziehungen sowie das zugeordnete Laufzeitsystem in Form von Artefakten |
| Kompositionsstrukturdiagramm | Zeigt die interne Struktur von Modellelementen und ermöglicht dadurch eine hierarchische Dekomposition |
| Kommunikationsdiagramm | Beschreibt einfache Interaktionen Fokus: strukturelle Beziehungen |
| Interaktionsübersichtsdiagramm | Zeigt auf abstrakter Ebene den Kontrollfluss zwischen verschiedenen Interaktionsabläufen |
| Use-Case-Diagramm | Graphische Sicht auf einen oder alle Akteure, Use Cases und ihre Interaktion im Zusammenhang mit einem System |
| IT-Landschaft | Welche Systeme werden in welchen Versionen betrieben? Über welche Schnittstellen wird zusammengearbeitet? Wo gibt es Verbesserungspotential? |
| Glossar | Ist-Analyse: Erschließung von Fachsprache, relevante Begriffe in Prosa definieren, Unterschiede im Gebrauch festhalten Soll-Konzept: Rekonstruktion von Fachsprache, Vereinheitlichung der Fachbegriffe, neue Begriffsbildung |
| Szenarien & Visionen | erzä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) |
| Leitfragen für Entscheidungen | Architecture Decision Records Textstruktur Datei mit 5 Infos: - Titel - Kontext - Entscheidung - Status - Auswirkung |
| Schnittstellendokumentation | Bedarf für Schnittstellendokumentation obwohl in Sichten enthalten - Identifikation - bereitgestellte Ressourcen - Fehlerszenarien - Variabilität/Konfigurierbarkeit - Qualitätseigenschaften - Entwurfsentscheidungen - Benutzungshinweise |
| ARC42 | |
| typische Architekturdokumente | zentrale Architekturbeschreibung Architekturüberblick Dokumentationsübersicht Übersichtspräsentation Architekturtapete Handbuch zur Architekturdokumentation technische Informationen zum Entwicklungsprozess |
Want to create your own Flashcards for free with GoConqr? Learn more.