Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

SWT > LE 7 | ARC - Objektorientierte Architekturen - DdB > Flashcards

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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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.)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
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
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Middleware-Architekturen (MOM)

A

Middleware-Architekturen (MOM)

  • Middleware sind Programme die die Komponenten und Kommunikationsarchitektur verstecken sollen
  • Middleware sorgt für Übermittlung komplexer und strukturierter Daten
  • Komponenten oder entsprechende Daten werden über Netzwerke in irgendeiner Form bereitgestellt (meist TCP/IP, http, WebServices)
17
Q

Serviceorientierte Architekturen (SOA)

A

Serviceorientierte Architekturen (SOA)

  • Strikte Ausrichtung auf Dienste
  • Alles unter einer einheitlichen Dienst-Schnittstelle zu Verfügung zu stellen
  • Mithilfe von SOA können einzelne Systeme gekapselt werden
  • SOA stellt meistens Adapter zur Verfügung (Austausch zwischen unterschiedlichen Systemen)
18
Q

Enterprise Service Bus (ESB)

A

Enterprise Service Bus (ESB)

  • Einheitliches Leitungsmedium (Bus) auf dem Producer Nachrichten verschicken welche von Consumern aufgenommen werden
  • Messaging-Infrastruktur
  • Filter, Konverter, Adapter zur Verbindung von unterschiedlichen Systemen mit dem Bus
19
Q

Peer-to-Peer (P2P)

A

Peer-to-Peer (P2P)

  • Rechnersysteme mit Komponenten/Teilnehmern die gleichberechtigt miteinander kommunizieren
  • Es gibt keinen zentralen Server
  • Systemzustand ist das System selbst und daher schwierig zu durchschauen
  • Organisieren sich selbst
  • Peers können anbieten und nutzen
  • Verhalten, Zustand, etc. erinnern an einen Schwarm z. B. Torrent
20
Q

Application Server

A

Application Server

  • Application Server bündeln mehrere der genannten Architekturen
    • Enthalten meist einen Container
      • Lieferung von Containerdiensten wie Persistenz, Security, Transaktionen
  • Bieten weitere Services an
    • Directory-Dienste, Kommunikationsdienste, etc.
  • Skalieren ohne Änderung der Anwendung
  • Logging und Monitoring
  • z. B. Tomcat, JBoss, Glassfish
21
Q

Ein guter Architekt …

A

Ein guter Architekt …

  • Kann Visualisieren
  • Diskutiert mit/anderen
  • Hat Designerfahrung
  • Kennt Design und Enterprise-Patterns
  • Kann strukturieren (trennen und gruppieren)
  • Hat Zuständigkeiten im Blick
  • Er versteht die Geschäftsanwerıdungsfälle
  • versteht, bewertet und gewichtet Aniorderungen
  • Entwirft eine Architektur
  • Kommuniziert die Architektur
  • Setzt und Architektur und betreibt Risikomanagement
    • Realisierung von Prototypen
    • Erstellen von Richtlinien
    • Kontrolle der Architektur

SWT (11 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions