LE 7 | ARC - Objektorientierte Architekturen - DdB Flashcards
1
Q
Gründe für eine gute Softwarearchitektur
A
Gründe für eine gute Softwarearchitektur
- Software sollte nicht als großer, unstrukturierter Haufen vorliegen (unübersichtlich)
- Komplexer Code kann besser verstanden werden
- Man findet sich besser zurecht
- Code kann einfacher erweitert werden
- Struktur im System spiegelt Domänen und Bereiche wieder, wodurch sie besser
- getrennt und einzeln bearbeitet werden können
- Korrektheit und Qualität lassen sich durch gute Architektur besser sicherstellen
- Wartung ist ein wesentliches Ziel der Softwarearchitektur
- Erreichen von Kohäsion
- lm Wesentlichen:
- Änderbarkeit
- Wartbarkeit
- Lesbarkeit
- Qualität
2
Q
Architektur Rahmen
A
Architektur Rahmen
-
Was?
- Die Art der Architektur (Software, Daten, Enterprise, etc.)
-
Wo?
- Auf welchen Software-Schichten?
- Wo befinden sich Komponenten?
- Welche Ebenen gibt es?
-
Warum?
- Warum diese Architektur für dieses Problem?
-
Womit?
- Welche Patterns und Frameworks, Technologiestacks, etc.
-
Wer?
- Architekt muss mit Designern, Anforderungsermittlern, Entwicklern austauschen um die passende Architektur zu finden
-
Wie?
- Vorgehensweise des Architekten
3
Q
Architektur Werkzeuge
A
Architektur Werkzeuge
- Ebenen zur Strukturierung des Systems (keine „TooIs”)
- Vision
- Architektur ist eine Vision vom Gesamtsystem und den einzelnen Bestandteilen
- Visionen können Spezifikationen ergänzen (z. B. Hinweise auf Patterns)
- Packages/ Namensgebungen
- Wichtigsten Gestaltungsmíttel für Architekten
- Namensräume helfen ideal bei der Strukturierung und Trennung
- Vertikal in Schichten (Packages)
- Horizontal in fachliche Komponenten (innerhalb der Schicht/ Klassen)
- Trennen und Gruppieren
- Dinge klein halten, statt zusammenzufassen, macht es einfacher
- Namensgebung beachten um zu trennen oder Zusammengehörigkeit anzuzeigen
- Patterns/ Kapselung / Abstraktion
- Design Pattern
- Ist eine Architektureinheit
- Design Pattern strukturiert Komponenten und gibt deren Kommunikation und Wechselwirkungen vor
- Kapselung
- Dinge nach außen verstecken
- Vermeidung von Spaghetticode
- Verringert Kopplung
- Klassen: public/ private Methoden
Packages: Fassaden-Pattern g
- Abstraktion
- Interfaces und Abstrakte Klassen verwenden
- Konzepte zur Abstraktion
- Richtige Mischung aus abstrakten und konkreten Komponenten ist weniger änderungsempfindlich
- Die Kopplung kann verringert werden
Kohäsion / Kopplung
- Kohäsion bestimmt die Zusammengehörigkeit von Komponenten
- Jede Komponente erfüllt genau ihre eine Aufgabe
- Fachliche Zusammengehörigkeit
- Bei der Package-Aufteilung beachten
- Kopplung
- Kopplung achtet nur auf Benutzrelationen
- Grad der Abhängigkeit zwischen Komponenten
- Schwache Kopplung erstrebenswert
- Dependency injection
- Patterns
- Kommunikation über Protokolle
- Stark gekoppelte Systeme werden als „spröde” bezeichnet
- Initial stabil aber bröckeln wenn sie größer werden
4
Q
Standards
A
Standards
- Die Entscheidung für eine bestimmte Technologie ist gleichzeitig eine Entscheidung für bestimmte Standards die eingehalten werden müssen
- Bsp. JEE: Verwendung von Java Beans
- Bsp. Ruby: MVC-Architektur
- Coding Standards
- Werkzeugstandards (JUnit, Ant, etc.)
5
Q
Architektur Prinzipien
A
Architektur Prinzipien
- lnkrementalität: durch prototyping und schrittweises Wachstum
- Lose Kopplung
- Entwurf für Veränderung: Testen was passiert, wenn Komponenten sich ändern
- Hohe Kohäsion: fachliche Technologie-Shifts
- Rückverfolgbarkeit: Änderungen, Datenfiüsse, Fehler transparent machen
- Abstraktion: Interface als explizite Schnittstelle, Subclassing, Polymorphie
- Information Hiding: Fassaden, Black-Box-Prinzip, Schichtenbildung
- Separation of Concems: Analyse der Zuständigkeiten
- Modularität: Anwendung der Sprachmittel für Gruppierung
- Selbstdokumentation: Namensgebung, interne und externe Dokumentation
6
Q
Architektur Ebenen
A
Architektur Ebenen
- Vertikale Ebene
- Technische Schichten
- Unterteilen, Benennen, Strukturieren
- Horizontale Ebene
- Fachliche Ausprägungen
- Views
- Controller
- Etc.
- Geschäftssicht:
- Fachlichkeit, Organisation, Geschäftsprozesse, etc.
- Logische Sicht:
- Bausteine der Anwendung, Schnittstellen, stanzen, etc.
- Datensicht:
- Datenbanken, Ein- und Ausgabequellen, Datenfluss
- Technologiesicht:
- Welche Tools, Frameworks, lDEs, Tests, etc. ?
- Verteilungssicht
- Deployment, Installation, Konfiguration, etc.
7
Q
Architekturstile
A
Architekturstile
- Quasi-Patterns für Architekturen
- Allgemeine Philosophie:
- Es gibt Komponentengruppen die miteinander agieren
- Wie ist die Anordnung der Komponenten?
- Was ist wem vorgeschaltet?
- Wer erbringt welche Aufgabe?
- Welche Topologie liegt vor?
- Konnektoren sind notwendig
- Über definierte Schnittstellen werden informationen ausgetauscht und abgerufen
- Es gibt Constraints
- Bedingungen die erfüllt werden müssen
- Einschränkungen was getan werden darf
- A darf nicht mit B kommunizieren
- Information Hiding darf nicht gebrochen werden
8
Q
Ordnung der Architekturstile
A
Ordnung der Architekturstile
- Die Erkenntnis von welcher „Problemklasse“ eine Aufgabenstellung ist legt schon einen Großteil der zu verwendenden Architektur fest.
-
Kommunizierende Prozesse
- Event-Systeme (impliziter/ expliziter Aufruf)
- Middleware Systeme die Nachrichten als Events auffassen
- Nachrichten werden in Queues gehalten und von dort aus weiterverarbeitet
-
Datenorientierter Fluss
- Stapelverarbeitung (Batch-Processing)
- Pipes & Filters
- Compiler
- Informationen werden kettenartig weitergereicht
- Jeder Filter trägt zur Verarbeitung bei
-
Call and Return
- Prozedurale Programmierung/ OO-Programmierung
- Schichtenorientiert
- Sichtweise in der Entwickler normalerweise arbeiten
-
Datenzentriert
- Repository
- Blackboard
- Repo: Objekte werden nach einem Schlüssel abgelegt
- Kernelement sind die gespeicherten Daten (können auch Logik enthalten)
- Blackboard: nicht deterministisch und zu großer lösungsraum
- Agenten bedienen sich an Teilen des BB und lösen Teilprobleme (Bilderkennung, DNA-Sequenzen, etc.)
-
Virtuelle Maschine
- lnterpreter
- Regelbasierte Systeme
- Problem kann in einer Sprache (DSL) oder in Form von Regeln vorliegen
- Ähnlich Automaten (Anfangszustand -> abarbeiten -> Ergebnis/Endzustand)
- Steuerungsprobleme in Hardware
- Suchanfragen im Semantic Web
9
Q
Technologiearchitekturen Übersicht
A
Technologiearchitekturen Übersicht
-
Übersicht (nicht vollständig)
- CMS
- Suchmaschinen
- Portal Frameworks
- Client-Server
- Rich- und Thin-Client
- N-Tier
- Container- / Komponenten-Architektur
- Middleware (MOM)
- Serviceorientiert (SOA)
- Enterprise Service Bus (ESB)
- Peer-to-Peer P2P
- Application Server
10
Q
Anti-Pattern: Monolith
A
Anti-Pattern: Monolith
- Monolithische Systeme sind keine Architektur sondern nur „ein großer Klumpen”.
- Sie sind nicht wartbar oder erweiterbar
- Passend für sehr, sehr kleine Projekte mit maximal einer Person
11
Q
Client-Server
A
Client-Server
- Zugriffszeiten: Verteiltes System oder nicht? (zentral / dezentral)
- Ausfallsicherheit: Datenbestände repliziert vorliegen oder nicht?
- Datenbestände oder Dienste liegen auf zentralen Servern und werden durch Clients genutzt (Online-Spiele, Google, etc.)
12
Q
Rich- Thinclient
A
Rich- Thinclient
- Wird ein Webbrowser zur Arbeit mit dem System benötigt oder nicht
- „echte“ Rich-Client = Desktopanwendung, Thin-Client = Browserzugriff
- Rich-Clients im Browser durch Silverlight/Air/Flex
13
Q
N-Tier
A
N-Tier
- Beschreibt eine Mehrschicht-Architektur
- Die meisten klassischen Systeme sind so gestaltet
- Einfachere Entwicklung durch Trennung der Schichten
- Auf allen Schichten kann verteilt werden was Load-Balancing, Ausfallsicherheit, etc. erhöhen kann
- Logik-Schicht, View-Schicht, Daten-Schicht
14
Q
Container / Komponentenarchitektur
A
Container / Komponentenarchitektur
- Containerarchitektur / Container-System
- Nimmt Komponenten auf
- Übernimmt Funktionalitäten wie Lastverteilung und Sicherheit
- Komponente wird durch den Container verwaltet (Pool)
- Transaktionen, Persistenz, Ressourcenmanagement, etc. sind
- standardisiert und es werden zu verwendende APIs bereitgestellt z.B. EJB, COM
15
Q
Komponentenarchitektur
A
Komponentenarchitektur
- Strukturierung eines Systems in Komponenten
- Komponente: Einheit von Code die eine definierte Schnittstelle hat.
- Hängt nur von sich selbst ab und kann dadurch mehrfach eingesetzt oder erweitert werden
