SAT alles

Zuordnung:

organisatorischer, technischer oder konzeptioneller Grund, nicht den ganzen Code in eine Datei zu schreiben?

a) selbst kleine Änderungen erfordern eine komplette Re-Compilation

b) Komplexität beherrschen erfordert übersichtliche Einheiten

c) viele Entwickler müssen koordiniert zusammenarbeiten

a = technisch b = konzeptionell c = organisatorisch Quelle: VL1 Folie 6

Wahr oder falsch?

Eine gute Softwarearchitektur führt zu steigenden Änderungskosten bei gleichbleibender Qualität.

FALSCH

• gute Architektur: Qualität bleibt hoch, Änderungskosten bleiben niedrig

• schlechte Architektur: Qualität sinkt, Änderungskosten steigen Quelle: VL1 Folie 8

Mehrfachauswahl:

Welche drei Aktivitäten im Software Engineering nennt die Vorlesung?

a) Projektmanagement

b) Requirements Elicitation

c) Deployment

d) Implementation

e) Design

f) Refactoring

• Requirements Elicitation

• Design

• Implementation

-

• Botschaft: Gleichgewicht – Features sind nicht wichtiger als gute Architekturarbeit Quelle: VL1 Folie 9

Wahr oder falsch?

Für Vitruv umfasste Architektur jede Art von Baukunst – nicht nur Gebäude, auch Maschinen.

WAHR

• Architektur = „Mutter aller Künste“ (zeitlich und als Rangfolge)

• Wortherkunft: architékton = Haupt-Baumeister Quelle: VL1 Folie 13

Zuordnung:

Was bedeuten Vitruvs Prinzipien Firmitas, Utilitas und Venustas?

• Firmitas = Stabilität

• Utilitas = Nützlichkeit

• Venustas = Anmut/Schönheit

• präskriptiv (Entwurf) und deskriptiv (Bewertung) anwendbar Quelle: VL1 Folie 15

Nenne die drei Aufgaben eines (Gebäude-)Architekten laut Vorlesung.

• Entwurf (Kernaufgabe: funktionale Ziele unter Einhaltung der Rahmenbedingungen erfüllen)

• Planung und Organisation

• Bauüberwachung (Planungsfehler früh erkennen, Leistungen abnehmen) Quelle: VL1 Folie 16

Wahr oder falsch?

Die Kernaufgabe des Architekten beim Entwurf ist ein gestalterisch schöner Entwurf.

FALSCH

• Kernaufgabe: funktionale Ziele unter Einhaltung der Rahmenbedingungen (Budget, Machbarkeit, Gesetze und Normen)

• „schön“ (stilistische Konsistenz) ist nur Nebenaufgabe

• Architekt = Bindeglied zwischen Analyse und Umsetzung Quelle: VL1 Folie 16

Wahr oder falsch?

Anders als Gebäudearchitektur ist Software-Architektur immateriell, schlecht sichtbar und schlecht messbar.

WAHR

• Software: kaum physikalische Gesetze, nur wenige Jahrzehnte Erfahrung, weiter starkes Wachstum an Größe und Komplexität

• Parallelen zur Gebäudearchitektur gibt es trotzdem (z. B. Vitruv, Aufgaben) Quelle: VL1 Folie 17

Wahr oder falsch?

Als „Artefakt“ bezeichnet man den Prozess der Erstellung, Strukturierung und Unterteilung von Software.

FALSCH – das ist die Aktivität

• Artefakt = dokumentierte Ergebnisse als Basis der Entwicklung

• Disziplin = Bereich, der Methoden und Werkzeuge bereitstellt Quelle: VL1 Folie 19

Lücke

(Klausur-Version): „Software-Architektur ist die grundlegende ___ eines Systems, dargestellt als eine Sammlung von ___ und deren ___ zueinander. Sie liefert ___ für getroffene architektonische Entscheidungen.“

• Organisation

• Komponenten

• „Abstände“ – so im Vortermin gewertet; auf der Folie steht „Beziehungen“

• Begründungen

Quelle: VL1 Folie 20–22

Wahr oder falsch?

Software-Architektur legt Leitlinien fest und trifft keine Einzelfallentscheidungen.

WAHR

• regelt strategische Dinge, keine Details

• plant kurz- und langfristig (Entwurf und Evolution) Quelle: VL1 Folie 22

Wahr oder falsch?

Verknüpfungen und Schnittstellen sind für eine Architektur genauso wichtig wie die Komponenten selbst.

WAHR

• „Beziehungen zueinander und zur Umgebung“ gehören zur Definition

• ein System ist kein Monolith, sondern zerlegbar Quelle: VL1 Folie 22

Wahr oder falsch?

Ein System ohne dokumentierte Architektur hat keine Architektur.

FALSCH – Architektur ist eine Tatsache, die immer existiert

• Dokumentation macht sie nur sichtbar

• dokumentiert wird nicht nur das „Was“, sondern auch das „Warum“; mehrere Sichten möglich Quelle: VL1 Folie 23

Zuordnung:

Requirements Engineering, Entwurf oder Architekturdefinition?

a) beschäftigt sich mit dem Problemraum, technikunabhängig

b) entwickelt Lösungen, technologiespezifisch

c) betrachtet beides und findet Kompromisse bei widersprüchlichen Anforderungen

a = Requirements Engineering

b = Entwurf

c = Architekturdefinition Quelle: VL1 Folie 24

Wahr oder falsch?

Eine Software-Architektur wird in der Regel nur durch Quellcode repräsentiert.

FALSCH

• Software-Architektur ist NICHT NUR Quellcode

• und auch NICHT NUR ein Diagramm Quelle: VL1 Folie 25

Nenne die vier Aufgaben einer guten Software-Architektur.

• trägt zur Effizienz des Entwicklungsprozesses bei (Entkopplung, Rahmen)

• hilft, Risiken zu minimieren

• ist ein wichtiges Kommunikationsmedium

• dient der Speicherung von Wissen (Einarbeitung, Wiederverwendung) Quelle: VL1 Folie 26

Wahr oder falsch?

Conway's Law (die Architektur entspricht der Organisationsstruktur) ist ein technischer Einflussfaktor auf die Architektur.

FALSCH – organisatorische Bedingung (wie Unternehmensziele, externe Lieferanten)

• technisch: Standards, Programmiersprachen, Zielplattformen, Ressourcen

• außerdem: funktionale/qualitative Ziele, Kompetenzen des Teams Quelle: VL1 Folie 27

Wahr oder falsch?

Qualitätsanforderungen kommen häufiger vor als funktionale Anforderungen und lassen sich kaum standardisieren.

FALSCH – vertauscht

• hauptsächlich individuelle, funktionale Anforderungen

• Qualitätsanforderungen seltener, dafür standardisierbar Quelle: VL1 Folie 27

Wahr oder falsch?

Eine Aufgabe der Architektur ist es, eine generische Flexibilität der Software zu erreichen.

FALSCH

• „hohe Flexibilität“ ist eine unklare, nicht messbare Anforderung

• Folgekosten: Abstraktionsschicht, Doku/Einarbeitung, Performance zur Laufzeit

• nur flexibilisieren, wo es fachlich nötig ist Quelle: VL1 Folie 28

Zuordnung:

Welche Architektur-Ebene?

a) Ressourcen, Betriebssysteme, Kommunikationsprotokolle, Middleware

b) Entitäten, Prozesse und Interaktionen aus Nutzersicht

c) Komponenten, Schnittstellen, Plattformen, Erfüllung der Qualitätsanforderungen

d) gesamte IT-Landschaft, Geschäftsprozesse, Unternehmensziele

a = systemtechnische Architektur

b = fachliche Architektur

c = softwaretechnische Architektur

d = Unternehmensarchitektur Quelle: VL1 Folie 29

Wahr oder falsch?

Die fachliche Architektur beschreibt Komponenten aus technischer Sicht der Entwickler.

FALSCH – aus Nutzersicht

• beschreibt fachliche Komponenten, Services und Schnittstellen, statische/dynamische Beziehungen, Datenhaushalt

• wird wichtiger: Business-IT-Alignment, Domänenmodelle, Produktlinien, digitale Transformation Quelle: VL1 Folie 32

Wahr oder falsch?

Die softwaretechnische Architektur ist eine Verfeinerung der fachlichen Architektur vor dem Hintergrund qualitativer Eigenschaften.

WAHR

• beschreibt Komponenten, Interfaces und Aufrufbeziehungen unter Verwendung eines Komponentenmodells

• Grundlage des Softwareentwurfs Quelle: VL1 Folie 34

Wahr oder falsch?

Die Softwarearchitektur hat “strategische Bedeutung”

Die Unternehmensarchitektur ist eine „operative Architektur“.

FALSCH – genau vertauscht

• Unternehmensarchitektur = strategisch: ganze IT-Landschaft, ständige Veränderung

• Softwarearchitektur = operativ: ein System, nach der Implementierung schlecht veränderbar, ersetzbar Quelle: VL1 Folie 36

Zuordnung (Beispiel Moodle):

Welche Architektur-Ebene?

-

a) mehrere Webserver mit PHP, Loadbalancing und Redundanz

b) eigene Logik-Komponente je Aufgabentyp mit einheitlichem Interface

c) es gibt Lehrende, Studierende, Aufgaben und Kurse

d) Regeln der UDE für Strukturen und strategische Bedeutung von IT-Systemen

a = systemtechnisch

b = softwaretechnisch

c = fachlich

d = Unternehmensarchitektur Quelle: VL1 Folie 37

Wahr oder falsch?

„Software-Architekt“ ist eine präzise definierte Berufsbezeichnung.

FALSCH – keine präzise definierte Bezeichnung

-

• kann ein kleiner Kreis hochqualifizierter Personen sein

• oder ein Synonym für „Senior Software Engineer“ bzw. „Projektleiter“ Quelle: VL1 Folie 38

Wahr oder falsch?

Entwurfsspezialisten arbeiten für übergreifende Architekturentscheidungen auf einem zu niedrigen Abstraktionsniveau.

WAHR – sie sind keine (generellen) Software-Architekten

• auch Plattformspezialisten (z. B. „J2EE-Architekt“) nicht: können nicht zwingend über die generelle Eignung ihrer Plattform entscheiden Quelle: VL1 Folie 39

Nenne die drei Eigenschaften eines Software-Architekten laut Vorlesung.

• kommunikativ: spricht mit allen Beteiligten, erkennt Risiken

• interdisziplinär: versteht die Domäne des Kunden zumindest rudimentär

• ökonomisch: wägt Aufwand und Nutzen ab, kurz- und langfristig Quelle: VL1 Folie 40

Nenne die drei typischen Fehlvorstellungen über Software-Architektur.

• „Gute Architektur löst die meisten Probleme“ – nein, auch andere Faktoren zählen

• „Man muss nur die richtigen Prinzipien konsequent anwenden“ – Prinzipien sind nur Leitplanken

• „Ein guter Architekt kann das alleine entscheiden“ – führt zu Over-Engineering Quelle: VL1 Folie 41

Wahr oder falsch?

Eine gute Software-Architektur löst die meisten Probleme von Software-Projekten.

FALSCH – typische Fehlvorstellung

• auch andere Faktoren verursachen Verzögerungen, Kosten und schlechte Wartbarkeit Quelle: VL1 Folie 41

Wahr oder falsch?

Ein Software-Architekt trifft Entscheidungen am besten alleine, um die Prinzipien unbeeinflusst konsequent anwenden zu können.

FALSCH – zwei Fehlvorstellungen in einem Satz

• große Freiheit → Perfektionismus → Over-Engineering

• Prinzipien sind Leitplanken; der Architekt vermittelt zwischen den Stakeholdern Quelle: VL1 Folie 41, 44

Welche drei Fragen schärfen die Architekturziele zu Projektbeginn?

• Was soll die Architektur leisten?

• Was wollen wir explizit nicht?

• Was soll sie möglicherweise in ferner Zukunft ermöglichen?

• erst aufschreiben WAS, noch nicht WIE – abgestimmt mit den Stakeholdern Quelle: VL1 Folie 43

Zuordnung:

Welcher Stakeholder fragt was? Qualitätssicherung · Betrieb · Projektleitung · Entwickler

• Qualitätssicherung: Wo lauern Risiken?

• Betrieb: Ist das umsetzbar?

• Projektleitung: Budget und Zielerreichung

• Entwickler: Komponenten, Schnittstellen, Fähigkeiten Quelle: VL1 Folie 44

Zuordnung (Stakeholder-Priorisierung nach Einfluss/Macht und Interesse/Betroffenheit): Welche Strategie?

a) hohe Macht, hohes Interesse

b) hohe Macht, geringes Interesse

c) geringe Macht, hohes Interesse

d) geringe Macht, geringes Interesse

a = Intensiver Austausch

b = Zufrieden stellen

c = Austauschen

d = Minimaler Aufwand Quelle: VL1 Folie 45

Praxis:

Eine Fachabteilung ist vom neuen System stark betroffen und sehr interessiert, hat aber kaum Einfluss auf Entscheidungen. Welche Strategie aus der Stakeholder-Matrix?

Austauschen

• geringe Macht

+ hohes Interesse

-

• zum Vergleich: kaum Macht + kaum Interesse = Minimaler Aufwand Quelle: VL1 Folie 45

Wahr oder falsch?

Software-Architekten konzentrieren sich auf Anforderungen mit besonderer Auswirkung auf die Architektur, behalten die übrigen aber im Blick.

WAHR

• ASRs = Architecturally Significant Requirements

• Architekten sind keine generellen Requirements Engineers; die übrigen Anforderungen dienen dem Systemverständnis Quelle: VL1 Folie 46

Mehrfachauswahl:

Was sind die zentralen Ziele der Kontextabgrenzung?

-

a) herausfinden, welche Hardware der Kunde bevorzugt

b) herausfinden, was zum zu entwickelnden System gehört

c) herausfinden, welche Design Patterns im Code nötig sind

d) herausfinden, was Teil des Systemkontexts ist bzw. welche Umsysteme es gibt

Richtig: b, d – beide Hälften der Folienfrage

• Umsysteme bestimmen den Bedarf an Schnittstellen

• zeigt, was Fokus der eigenen Architektur ist Quelle: VL1 Folie 47

Zuordnung:

Fachlicher oder technischer Kontext?

-

a) zeigt Übertragungen und Protokolle, Infrastruktur wird sichtbar

b) zeigt die fachlichen Nachbarn, Pfeile beschreiben Abhängigkeiten und Datenflüsse

a = technischer Kontext (nur bei Bedarf)

b = fachlicher Kontext Quelle: VL1 Folie

Wahr oder falsch?

Gesamtsysteme werden aus Komponenten als Bausteinen zusammengesetzt, deren Innenleben nicht betrachtet wird.

WAHR

• Komponenten = äußerlich gleichmäßig geformte Bausteine

• lose Kopplung zur Umgebung, Funktionalität über eine oder mehrere Schnittstellen beschrieben Quelle: VL2 Folie 4

Wahr oder falsch?

Das Komponenten-Konzept in Programmiersprachen ist immer deckungsgleich mit dem Komponenten-Konzept der Software-Architektur.

FALSCH – „nicht immer deckungsgleich“ Quelle: VL2 Folie 4

Wahr oder falsch?

Eine Konfiguration aus mehreren Komponenten kann selbst wieder als einzelne Komponente betrachtet werden.

WAHR

• Konfiguration = zusammengefügte Bausteine

• nach außen egal, ob eine einzelne oder eine zusammengesetzte Komponente die Aufgabe erledigt Quelle: VL2 Folie 4, 11

Wahr oder falsch?

Für dieselbe Komponente kann für verschiedene Komponenteninstanzen ein Komponentenmodell entwickelt werden.

FALSCH – zwei Begriffe vertauscht

• richtig: für verschiedene Komponentenmodelle kann je eine Komponenteninstanz entwickelt werden

• für dieselbe Komponente mehrere Komponenteninstanzen (Implementierungen) möglich, zur Laufzeit mehrere Instanzen

• Komponentenmodelle = Ausführungsumgebungen zur Laufzeit Quelle: VL2 Folie 5

Lücke: „Komponentenbasierte Entwicklung ist eine Weiterentwicklung der ___ Entwicklung. Zentraler Ansatz ist die ___ von kompletten Lösungen statt nur Lösungsansätzen.“

• objekt-orientierten

• Wiederverwendung (auch von Lösungen an entfernten Orten) Quelle: VL2 Folie 6

Nenne die vier erreichbaren Ziele komponentenbasierter Entwicklung.

• Zeitersparnis

• bessere Softwarequalität

• Plattformunabhängigkeit

• Handel mit Komponenten statt mit fertigen Systemen Quelle: VL2 Folie 6

Mehrfachauswahl:

Welche Aussagen zur komponentenbasierten Entwicklung sind korrekt?

-

a) Plattformunabhängigkeit ist damit nicht erreichbar

b) Zeitersparnis und bessere Qualität durch Wiederverwendung

c) das Testen des Gesamtsystems kann durch das Zusammenspiel komplexer werden

d) das Testen wird durch fertige, getestete Komponenten erheblich einfacher

e) Abhängigkeit von Drittanbieter-Komponenten kann zu Integrationsproblemen führen

f) weniger Overhead bei der Projektplanung

Richtig: b, c, e

• a gedreht: Plattformunabhängigkeit ist ein Ziel

• d und f klingen gut, sind aber falsch – jedes falsche Kreuz frisst ein richtiges Quelle: VL2 Folie 6 (+ Vortermin Frage 20)

Lücke:

Komponenten sollen nicht an einen bestimmten Einsatzort gebunden sein. Diese notwendige Eigenschaft heißt ___.

Ortstransparenz

• Falle: nicht „Plattformunabhängigkeit“ – das ist ein Ziel, keine Eigenschaft

• weitere Eigenschaften: wohldefinierter Zweck, Kontextunabhängigkeit, Portabilität, Selbstbeschreibungsfähigkeit, sofortige Einsatzbereitschaft, Integrations- und Kompositionsfähigkeit Quelle: VL2 Folie 7

Wahr oder falsch?

Die Trennung von Implementierung und Schnittstelle ist eine notwendige Eigenschaft von Komponenten.

WAHR

• strikte Trennung: was die Komponente intern tut vs. wie sie nach außen ansprechbar ist Quelle: VL2 Folie 7

Wahr oder falsch?

Der Export einer Komponente ist die konkrete Beschreibung ihrer Realisierung auf semantischer und syntaktischer Ebene.

FALSCH

• Export = abstraktes Bild der Realisierung (definiert die benutzbaren Eigenschaften)

• Import = abstraktes Bild der zu benutzenden Komponenten (erwartete Eigenschaften) Quelle: VL2 Folie 8–9

Wahr oder falsch?

Der Import einer Komponente verweist direkt auf eine konkrete andere Komponente.

FALSCH – formaler Import: benennt nur abstrakte Anforderungen an die zu benutzende Komponente

• deshalb ist der Import ein Parameter

• zum Nutzen darf das Verständnis der Realisierung nicht nötig sein Quelle: VL2 Folie 9, 20

Warum werden Konnektoren oft als zweites Grundelement neben Komponenten genannt?

• eine Verbindung entlang abstrakter Schnittstellen verpflichtet, Korrektheit zu prüfen

• syntaktisch: Signatur, Operationsköpfe

• semantisch: formale Schnittstellendefinition, Pfadausdrücke

Quelle: VL2 Folie 10

Wahr oder falsch?

In einer „A benutzt B“-Beziehung (unbedingte Abhängigkeit) darf eine Komponente von sich selbst abhängig sein.

FALSCH

– keine Komponente darf von sich selbst abhängig sein, auch nicht über einen Umweg

• nach außen zählen nur die „obersten“ Exports und die „untersten“ Imports Quelle: VL2 Folie 11, 13

A1 und A2 benutzen jeweils B. Was ist Gesamtimport und Gesamtexport? Und wenn A die Komponenten B1 und B2 benutzt?

• Fall 1: Gesamtimport = Import von B; Gesamtexport = Export von A1 + Export von A2

• Fall 2: Gesamtimport = Import von B1 + Import von B2; Gesamtexport = Export von A Quelle: VL2 Folie 12

Wahr oder falsch?

Wird eine Komponente an wesentlichen Punkten geändert, passt sie weiterhin problemlos in den bestehenden Kontext.

FALSCH

– es entsteht im Allgemeinen eine neue Komponente, die nicht mehr in den Kontext passt

• Grund: Schnittstellen sind Abstraktionen der Realisierung Quelle: VL2 Folie 16

Wahr oder falsch?

Wird eine Komponente ersetzt, erwartet die neue Komponente gleiche oder stärkere Vorbedingungen.

FALSCH – gedreht: gleiche oder schwächere Vorbedingungen

• Eselsbrücke (Liskov'sches Substitutionsprinzip): weniger fordern, mehr liefern Quelle: VL2 Folie 17

Wahr oder falsch?

Beim Ersetzen einer Komponente muss die neue Komponente gleiche oder schwächere Invarianten garantieren.

FALSCH – gedreht: gleiche oder stärkere Invarianten (= Regeln) Quelle: VL2 Folie 17

Wahr oder falsch?

Beim Ersetzen einer Komponente muss die neue Komponente gleiche oder stärkere Nachbedingungen sichern.

WAHR

• Merke: Invarianten und Nachbedingungen gleich oder stärker, Vorbedingungen gleich oder schwächer

• der Austausch einer Komponenteninstanz ist dagegen jederzeit möglich Quelle: VL2 Folie 17

Zuordnung:

Wann wird welcher Parametertyp aktualisiert?

-

a) Ein-/Ausgabeparameter (Methodenköpfe)

b) Systemparameter (gelten für die ganze Konfiguration)

c) Komponentenparameter (Imports/Exports)

a = bei der Ausführung des Systems

b = bei Systemkonfiguration / Systemstart

c = bei Komponentenkonfiguration / -integration (wichtigste Parameterart)

Quelle: VL2 Folie 19–22

Wahr oder falsch?

„Common Parameters“ sind Systemparameter, die von jeder Komponente sowohl importiert als auch exportiert werden.

WAHR

• Schnittmenge von Gesamtimport und Gesamtexport

• Teilmenge der Systemparameter Quelle: VL2 Folie 23

Wie bestimmt man den Gesamtexport einer Konfiguration?

• Wurzelkomponente(n) bestimmen = Komponenten, die von keiner anderen benutzt werden

• Export des Systems = disjunkte Vereinigung der Exports der Wurzelkomponenten

• danach formale Importe schrittweise befriedigen, bis alle erfüllt sind Quelle: VL2 Folie 24–25

Wie macht UML eine Komponente kenntlich – und was sind die kleinen Quadrate am Rand?

• Komponente = Rechteck wie eine Klasse, gekennzeichnet durch textuellen Stereotyp «component» oder grafischen Stereotyp (Komponentensymbol oben rechts)

• kleine Quadrate am Rand = Ports (keine Basisereignisse!)

• dieselbe Komponente mehrfach abzubilden ist kein Syntaxfehler Quelle: VL2 Folie 27–29 (+ Vortermin Frage 22)

Zuordnung (UML-Port-/Lollipop-Notation): Kreis („Lollipop“) oder Halbkreis („Socket“)?

-

a) bereitgestellte Schnittstelle (provided interface)

b) benötigte Schnittstelle (required interface)

a = Kreis / Lollipop

b = Halbkreis / Socket

-

• ein System darf gleichzeitig Schnittstellen bereitstellen und benötigen – das ist kein Fehler Quelle: VL2 Folie 28–29

Zuordnung:

Delegation Connector oder Assembly Connector?

-

a) verbindet einen äußeren Port der Gesamtkomponente mit einer inneren Komponente

b) verbindet zwei Komponenten (benötigt ↔ bereitgestellt) auf gleicher Ebene

a = Delegation Connector

b = Assembly Connector

-

• Falle: die Linie zwischen zwei inneren Komponenten ist KEIN Delegation Connector Quelle: VL2 Folie 30

Zuordnung:

Welches UML-Diagramm?

-

a) Verallgemeinerung von Komponentendiagrammen mit Parts, Kollaborationen und Rollen

b) Softwarestruktur aus Entwicklersicht mit „import“, „access“, „merge“

c) Richtung und zeitliche Reihenfolge von Nachrichten

d) Zuordnung von Software-Komponenten zu Hardware-Ressourcen

a = Kompositionsstrukturdiagramm

b = Paketdiagramm

c = Kommunikationsdiagramm

d = Deployment-Diagramm Quelle: VL2 Folie 31–32

Wahr oder falsch?

Für jede Architektur reichen UML-Komponentendiagramme zur Beschreibung aus.

FALSCH

– je nach Zweck reichen sie, oder es braucht speziellere Notationen (ADLs, z. B. Darwin, Wright)

• ADLs: grafisch oder textuell, oft mit Codegenerierung und Darstellung verbreiteter Architekturstile Quelle: VL2 Folie 33–34

Wahr oder falsch?

Architekturstile und -muster erlauben die Wiederverwendung von Konzepten.

WAHR – bewährte Muster statt Entwurf „bei Null“

• Architekturentwurf bei Null ist aufwändig und fehleranfällig Quelle: VL2 Folie 36

Ordne nach Domänenwissen (gering → hoch):

Architekturmuster

Entwurfsmuster

domänenspezifische Softwarearchitekturen

Architekturstile

Entwurfsmuster → Architekturstile → Architekturmuster → domänenspezifische Softwarearchitekturen

• je mehr Domänenwissen, desto höher auch der Detailgrad Quelle: VL2 Folie 37

Wahr oder falsch?

Die Unterscheidung zwischen Architekturstilen und -mustern ist nicht immer scharf.

WAHR

• wird an verschiedenen Stellen unterschiedlich getroffen Quelle: VL2 Folie 38

Was erfordert mehr Domänenwissen?
Archiekturstile - Entwurfsmuster

Entwurfsmuster erfordern etwas mehr

• beide beziehen sich auf ein begrenztes Problem in einem Kontext und fördern positive Eigenschaften

• Kataloge wie bei Entwurfsmustern gibt es für Stile nicht Quelle: VL2 Folie 39

Wahr oder falsch?

Das Entwurfsmuster Observer ist ein Beispiel für implizite Aufrufe; die zugehörigen Architekturstile sind Publish-Subscribe und Event-based.

WAHR

• welcher Stil besser passt, hängt von der Kommunikation ab (Menge/Größe der Nachrichten, Zahl der Beteiligten) Quelle: VL2 Folie 40

Praxis: Empfänger melden sich bei interessanten Sendern an. Die Sender führen eine Empfängerliste und schicken Benachrichtigungen als Broadcast an alle auf der Liste. Welcher Architekturstil?

Publish-Subscribe

• Vorteile: sehr lose Kopplung, effiziente Verbreitung in eine Richtung, individuelle Verschlüsselung möglich

• Nachteil: viele Empfänger pro Sender brauchen spezielle Kommunikationsprotokolle Quelle: VL2 Folie 41–42

Wahr oder falsch?

Beim Architekturstil „Publish-Subscribe“ werden Daten auch dann gesendet, wenn es keinen Empfänger gibt.

FALSCH – Infos ohne Empfänger brauchen gar nicht erst bereitgestellt zu werden

• „Überproduktion von Events“ ist ein Nachteil von Event-based Quelle: VL2 Folie 42

Wahr oder falsch? Beim Architekturstil „Publish-Subscribe“ entsteht möglicherweise ein Overhead an Nachrichten.

WAHR – Anmeldung, Benachrichtigung und Abholung können unnötigen Overhead erzeugen

• dann ist Event-based eine Alternative (kein Overhead für An-/Abmeldungen) Quelle: VL2 Folie 43–44

Praxis: Alle Komponenten schicken Nachrichten auf einen gemeinsamen Kanal und lesen dort, was sie interessiert. Sender und Empfänger lassen sich nicht unterscheiden. Welcher Architekturstil?

Event-based (gemeinsamer Event-Bus) • Vorteile: gut skalierbar, effektiv für stark verteilte, heterogene Systeme

• Nachteile: Überproduktion von Events, keine Kontrolle über die Verarbeitung, Vertraulichkeit schwierig Quelle: VL2 Folie 43–44

Praxis:

Für jede Aufgabe gibt es eine Komponente, die ein geschlossenes Datenpaket annimmt, komplett verarbeitet und zurückgibt. Zwischenergebnisse werden explizit gespeichert. Welcher Architekturstil?

Batch-Sequential – einer der ältesten Stile (Datenfluss)

• konzeptionell sehr einfach (keine Parallelität, keine Interrupts) – zählt als Vor- UND Nachteil

• Nachteil: keine Interaktion; trotzdem in der Realität sehr verbreitet Quelle: VL2 Folie 45–46

Wahr oder falsch?

Der Architekturstil „Batch-Sequential“ stellt keine besonderen Anforderungen an die verarbeiteten Daten.

FALSCH – geschlossene Datenpakete in genau definierten Datenformaten

• Pipes-and-Filters dagegen: Format nicht vorgegeben, Daten nur als Strom linearisierbar Quelle: VL2 Folie 45, 47

Praxis:

Audiodaten fließen nicht als geschlossene Pakete, sondern kontinuierlich als Datenstrom durch mehrere unabhängige Verarbeitungsschritte, die parallel arbeiten. Welcher Architekturstil?

Pipes-and-Filters

• alle Komponenten dürfen parallel arbeiten; Router für Datenströme

• Nachteile: nicht alle Daten sind als Strom verarbeitbar, keine Interaktion

• Wechsel von Batch-Sequential zu Pipes-and-Filters = in Strömen statt Paketen denken Quelle: VL2 Folie 47–48, 63

Wahr oder falsch?

Architekturstile beziehen sich auf abstraktere, kontextübergreifende Problemstellungen als Architekturmuster.

FALSCH – vertauscht

• Stile: relativ eng begrenzte Problemstellungen

• Muster: abstraktere, kontextübergreifende Probleme, mehr domänenspezifisches Wissen Quelle: VL2 Folie 49

Praxis:

Eine klassische Geschäftsanwendung (oder ein Browser-Spiel) besteht aus GUI, Geschäftsregeln und Kundendaten. Die Anzeige spricht nie direkt mit den Daten. Welches Architekturmuster?

State-Logic-Display = „Three-Tier“

• Nachteil: keine direkte Verbindung Display ↔ State – Logic wird in beide Richtungen genutzt

• Vorteile: passt zur Schichten-Sicht, gut für verteilte Systeme; Kommunikation z. B. per RPC oder HTTP Quelle: VL2 Folie 50–51

Wahr oder falsch?

Das Architekturmuster „Model-View-Controller“ wird auch „Three-Tier“ genannt.

FALSCH – „Three-Tier“ ist State-Logic-Display

• MVC hat eine direkte Verbindung Model ↔ View, Three-Tier keine Verbindung Display ↔ State Quelle: VL2 Folie 50–53

Praxis:

Eine GUI-Anwendung trennt die Geschäftslogik strikt von der Anzeigelogik. Die Anzeige meldet sich (z. B. per Observer) an, um über Zustandsänderungen informiert zu werden. Welches Architekturmuster?

Model-View-Controller (MVC)

• Einsatzbereich: interaktive, grafische Benutzerschnittstellen

• Nachteil: in der Realität oft enge Kopplung View ↔ Controller; Alternative: PAC Quelle: VL2 Folie 52–53

MVC in Worten:

Was kapselt Model, View und Controller – und wohin gehen „Ereignisse/Interaktionen“ und „grafische Anzeige“?

• Model = Kapselung von Informationen

• View = Kapselung von Darstellungsoptionen → erzeugt die grafische Anzeige

• Controller = Kapselung von Interaktionssemantik → nimmt Ereignisse/Interaktionen entgegen

• View und Model sind direkt verbunden (z. B. Observer) Quelle: VL2 Folie 52

Praxis:

Ein eingebettetes Steuersystem liest in einer Schleife alle Sensorwerte, berechnet daraus Steuerwerte und schickt sie an alle Aktoren. Welches Architekturmuster?

Sense-Compute-Control (SCC) – ein Muster, kein Stil

• Annahme: indirekte Verbindung von Aktoren zu Sensoren über die Umgebung

• keine Komponente wie „State“ oder „Model“ → Datenspeicherung erfordert Zusatzaufwand

• Vorteile: beliebig viele Sensoren/Aktoren, Real-Time-fähig, Algorithmus austauschbar Quelle: VL2 Folie 54–55

Was beinhaltet eine domänenspezifische Softwarearchitektur (DSSA) typischerweise?

• Referenzarchitektur für die Domäne

• Sammlung wiederverwendbarer, domänenspezifischer Komponenten

• Methode zur Auswahl und Konfiguration der Komponenten → so entstehen Softwareproduktlinien

• selten formal/öffentlich definiert, außerhalb der Domäne nur beschränkt nützlich Quelle: VL2 Folie 59–61

Wahr oder falsch?

Architekturstile und -muster sind sowohl deskriptiv als auch präskriptiv.

WAHR

• deskriptiv: benennen Designelemente und ihre Anordnung

• präskriptiv: machen Vorgaben und Einschränkungen; dokumentiert schützen sie Entscheidungen vor Erosion Quelle: VL2 Folie 62

Wahr oder falsch?

Weil Architekturen „fraktale Eigenschaften“ haben, sind sie in x Schritten vorhersehbar planbar.

FALSCH – gerade deshalb NICHT vorhersehbar in x Schritten planbar

• fraktal: eine Komponente eines Musters ist bei genauerem Hinsehen wieder eine Konfiguration mit eigenem Stil/Muster (z. B. Drei-Schichten-Architektur mit JSF, das MVC-ähnlich ist) Quelle: VL2 Folie 64

Zuordnung: Architekturstil oder Architekturmuster?

Client-Server

Schichtenarchitektur

Pipes & Filters

Sense-Compute-Control

Event-Driven

State-Logic-Display

Microservices

MVC

Batch-Sequential

Stile :

Client-Server

Microservices

Event-Driven

Pipes & Filters

Batch-Sequential

-

Muster :

MVC

Schichtenarchitektur

State-Logic-Display

Sense-Compute-Control

Fallen aus dem Vortermin:

• Client-Server = Stil

• Sense-Compute-Control = Muster

Zuordnung:

Entwurfsmuster oder Architekturmuster?

-

Observer

MVC

Singleton

Strategy

State-Logic-Display

Decorator

Factory Method

• Entwurfsmuster (niedrige Ebene, Softwareentwurf):

Singleton

Factory Method

Observer

Strategy

Decorator

-

• Architekturmuster:

MVC

State-Logic-Display

-

• Falle: MVC nutzt zwar Observer, ist selbst aber ein Architekturmuster Quelle: VL2 Folie 52, 65

Wahr oder falsch?

Ein Entwurfsmuster wird durch Programmcode repräsentiert, den man immer wieder verwenden soll.

FALSCH – es dokumentiert bewährte Erfahrung

• besteht aus Kontext, (wiederkehrendem) Problem und (bewährter) Lösung

• wiederverwendet werden Mengen von Klassen und ihre Beziehungen, nicht einzelne Klassen Quelle: VL2 Folie 66

Zuordnung:

Erzeuger-, Struktur- oder Verhaltensmuster?

· Singleton

· Observer

· Adapter

· Factory Method

· State

· Decorator

Erzeugermuster:

· Singleton

· Factory Method

Verhaltensmuster:

· Observer

· State

Strukturmuster:

· Adapter

· Decorator

Wofür legt ein Komponentenmodell Standards fest?

• Beschreibung, Verbindung, Kommunikation und Deployment von Komponenten

• zusätzlich möglich: Versionierung, Sicherheit

• kein aktuelles Komponentenmodell setzt die Theorie komplett um Quelle: VL2 Folie 72–73

Wahr oder falsch?

Laut Theorie erfordert eine Änderung der Konfiguration einen Neustart; einige Komponentenmodelle erlauben dagegen den Austausch von Komponenten zur Laufzeit.

WAHR

• Theorie: Komponentenparameter werden bei der Integration aktualisiert

• zur Laufzeit müssen Verbindungen dann regelmäßig neu aktualisiert werden Quelle: VL2 Folie 74

Wahr oder falsch?

Bei OSGi importiert „Import-Package“ ein ganzes Bundle.

FALSCH – Import-Package importiert ein Java-Paket, Require-Bundle ein ganzes Bundle (= Komponente)

• importiert werden kann nur, was andere per Export-Package freigeben

• OSGi: keine semantische Beschreibung von Schnittstellen Quelle: VL2 Folie 77–85

Wahr oder falsch? Ein Application Server führt Komponenten direkt aus.

FALSCH – er führt Container aus, die Komponenten zweckspezifisch verwalten

• Container hier nicht mit Docker & Co. verwechseln

• er erzeugt abhängige Instanzen selbst (keine explizite Erzeugung im Code) – vgl. @Inject in Übung 6 Quelle: VL2 Folie 86–89

Zuordnung (EJB Session Beans):

@Stateful

@Stateless

@Singleton

-

a) keine serverseitige Abhängigkeit zwischen zwei Anfragen

b) Daten in der Sitzung, exklusiver Zugriff des Clients

c) zustandsbehaftet mit nur einer Instanz

a = @Stateless

b = @Stateful (komplexere Abläufe, aber viel Speicher)

c = @Singleton Quelle: VL2 Folie 1

Wahr oder falsch?

Anwendungslandschaften sind homogen und nutzen in allen Anwendungen dieselbe Programmiersprache.

FALSCH – heterogen: Programmiersprachen, Zielgruppen, Nutzungsintensität

• nicht jede Anwendung leistet gleich viel für die Unternehmensziele

• Teile sollten unabhängig voneinander austauschbar sein

Quelle: VL4 Folie 6

Bringe die SOA-Layer in die Reihenfolge von oben nach unten:

Service · Object · Enterprise · Component · Process

Enterprise → Process → Service → Component → Object

• der Service Layer teilt sich in Aggregated Services und Atomic Services

• SOA: vager Begriff aus Mitte der 1990er, stark an Geschäftsprozessen orientiert

Quelle: VL4 Folie 8

Wahr oder falsch?

Ein SOA-Service wird erst zur Laufzeit gefunden und gebunden.

WAHR – „dynamically bound“

• weitere Merkmale: self-contained (unabhängig deploybar), verteilte Komponente, veröffentlichte Schnittstelle, interoperabel, auffindbar (discoverable)

Quelle: VL4 Folie 9

Zuordnung:

Komponente oder Service?

• Wiederverwendung durch Einbettung

• Wiederverwendung durch Verweise

• Verteilung ist Grundprinzip

• Verteilung erfordert Zusatzaufwand

• eigenständiges System

• Bestandteil selbstständiger Systeme

Komponente:

• Einbettung (je System eine eigene Instanz)

• Bestandteil selbstständiger Systeme

• Verteilung erfordert Zusatzaufwand

Service:

• Verweise (mehrere Systeme nutzen dieselbe Instanz)

• eigenständiges System

• Verteilung ist Grundprinzip

Quelle: VL4 Folie 10

Wahr oder falsch?

Service und Komponente sind synonyme Begriffe.

FALSCH – sie unterscheiden sich in Wiederverwendung, Eigenständigkeit und Verteilung

• die Unterschiede gelten für SOA und Microservices gleichermaßen

Quelle: VL4 Folie 10, 22

Welche Ziele und Voraussetzungen gelten bei Analyse und Design von Services?

• Ziel Wiederverwendung: Spezifikation nur einmal (DRY), Zuständigkeiten klar

• Ziel lose Kopplung: Verträge („Design by Contract“)

• nötig: gemeinsame Definitionen von Daten, Datentypen, Schnittstellen

• Vorgehen: Geschäftsprozesse modellieren → Services identifizieren, kategorisieren, spezifizieren → realisieren

Quelle: VL4 Folie 11–12

Zuordnung: Orchestrierung oder Choreografie?

a) ein „Dirigent“ (Process Engine) koordiniert die Services

b) mehrere selbstständige Services interagieren direkt miteinander

a = Orchestrierung

b = Choreografie

• Geschäftsprozesse (z. B. BPMN, BPEL) koordinieren Services; Microservices verzichten auf zentrale Orchestrierung

Quelle: VL4 Folie 13, 22