AI Flashcards

1
Q

Was sind Ziele der Softwarearchitektur Vorlesung?

A
  • Was ist Softwarearchitektur?
  • Große Systeme gut aufbauen und entwickeln.
  • Wie dokumentiert man und bewertet man Architekturen?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Was sind keine Ziele der Softwarearchitektur Vorlesung?

A
  • Die perfekte Architektur festzulegen.
  • Sich in technische Details von Frameworks zu verlieren.
  • Noch mehr UML Vorlesungen zu halten.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Woher stammt der Begriff Architektur und wofür steht er?

A

Architektur stammt ausdem Mittelalter und steht für die Baukunst.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Welches Ziel verfolgt Architektur?

A
  • Ordnung und Strukturierung von Produkten des Bauwesens
  • Erfahrungen und Wissen der Baukunst verallgemeinern.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Welchen Zweck hat Architektur in der Baukunst?

A

Verschiedene:

  • Macht demonstrieren
  • Verteidigen
  • Verkehr lenken
  • Mobil sein
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Was sind Definitionen von Softwarearchitektur?

A
  • Softwarearchitektur ist ein Gerüst aus Komponenten und Beschreibungen aus Software mit Ingenieurs Prinzipien
  • Softwarearchitektur ist durch die Aspekte bestimmt, welche man am schwersten im nachhinein ändern kann
  • Es geht darum eine Lösung für Anforderungen zu erstellen
  • Softwarearchitektur ist das WAS WIE WARUM
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

In welcher Reihenfolge entsteht eine Softwarearchitektur im Idealfall?

A
  • Vorwärts und nicht rückwärts durch Reverse-Engineering
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Woraus besteht Softwarearchitektur?

A
  • Nacheinander getroffene, weitreichende Entwurfsentscheidungen
  • Besteht aus Strukturen (Bausteine, Eigenschafte dieser Komponenten und Beziehungen der Komponenten untereinander)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Ist mit der Erstellung der Architektur für Software bereits der Job getan?

A
  • Nein, denn die Architektur sorgt nur für die Grundpläne.
  • Erst die Implementierung der Schnittstellen und Komponenten erschafft ein echtes System.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Auf welchen Entwurfsentscheidungen basiert Softwarearchitektur?

A
  • Entscheidungen über Entwürfe der Komponenten
  • Entscheidungen über benutzte Technologien
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Sind die Konsequenzen bei Entscheidungen in Softwarearchitektur leicht abschätzbar?

A
  • Nein, die Konsequenzen werden erst während der Umsetzungen bewusst.
  • Getroffene Konsequenzen schränken die Möglichkeiten immer weiter ein.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Sollte man Entscheidungen in der Softwarearchitektur auch nach dem besten Gewissen treffen?

A

Ja, da man Entscheidungen oftmals nicht komplett abschätzen kann.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Laufen heutige Softwaresysteme eher isoliert?

A

Nein, viele haben Abhängigkeiten zu Drittsysteme oder müssen bestimmte Anforderungen liefern.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Welche Sicht beschreibt das Zusammenspiel eines Softwaresystems?

A

Die Laufzeitsicht

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Welche Sicht beschreibt die Zusammenhänge eines Softwaresystems?

A

Die Bausteinsicht

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Welche Sicht beschreibt die ob ein Softwaresystem zentral oder dezentral aufgebaut ist?

A

Die Verteilungssicht

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Warum ist eine Dokumentation einer Softwarearchitektur wichtig?

A
  • Remotearbeiter müssen auch informiert sein
  • Wartungsteams bekommen später das System vorgesetzt und sollen es aktualisieren oder performanter machen, was nur mit Planen geht
  • Der Betreiber möchte auch wissen was auf welchem System läuft
  • Dokumentation entscheidet ob ein System weiterentwickelbar ist oder nicht
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Was muss alles dokumentiert werden?

A
  • Alles was man benötigt um das System zu verstehen
  • Alles andere kann auch weggelassen werden
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Für was ist Softwarearchitektur der Übergang?

A

Es ist der Übergang von der Analyse zur Architektur zur technischen Realisierung

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Dokumentiert eine Architektur ein gesamtes System?

A

Nein, eine Architektur dokumentiert immer sehr spezifische einzelne Aspekte eines Gesamtsystems.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Ist eine dokumentierte Architektur für jeden Stakeholder interessant?

A

Nein, je nach Dokumentationsart/Sicht ist diese für einen anderen Stakeholder mit verschiedenen Anforderungen interessant.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Was stellt das Nutzen von Softwarearchitektur sicher?

A
  • Flexibilität
  • Erweiterbarkeit
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

Warum ist Softwarearchitektur Abstraktion?

A
  • Weil ganz bewusst nicht benötigte Informationen weggelassen werden
  • Informationen müssen lesbar und nachvollziehbar sein
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Gibt es eine All-In-One Architekturlösung?

A

Nein

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

Was zeichnet die Qualität eines Systems aus?

A

Die Summe seiner nicht-funktionalen (schwierigen) Eigenschaften wie:

  • Performance
  • Verständlichkeit
  • Flexibilität
  • Wartbarkeit
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

Wie sieht die Grenze zwischen Entfurf/Design und Architektur aus?

A

Sehr fließend, man wird auch Designentscheidungen treffen, welche die Architektur einschränken.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Was ist NICHT Architektur?

A

Nur ein Diagramm. (“Das hier ist unsere Architektur”)
Denn das sind nur Striche und Buchstaben, welche Dutzende Fragen aufkommen lassen.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

Welche Fragen lassen Diagramme zur Architektur aufkommen?

A

Welche Verbindungen zwischen den Komponenten gibt es? Welche Richtungen haben diese?
Warum machen sie es so?
Was ist der Vertrag oder die Schnittstelle zwischen diesen?(Bei REST wichtig!)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Welche Entscheidungen trifft ein Architekt?

A
  • Brauche ich ein Framework und wenn ja welches?
  • Nach System in Komponenten gebrochen -> Baut man es selber oder kauft man es ein? Oder kann man etwas Open-Source bestehendes nutzen? (Mittelweg)
  • Wer arbeitet woran?
  • Naming (Namen sind schnell vergeben aber extrem wichtig)
    *
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

Was hat es mit den Konsequenzen aus Entscheidungen mit sich?

A
  • Oftmals werden sie erst Monate oder Jahre später bekannt
  • Oftmals sind Frameworks/Technologien unbekannt und die Auswirkungen nicht abschätzbar
    *
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Wie sollte man mit Entscheidungen bei der Architektur verantwortungsvoll umgehen?

A
  • Die Entscheidungen iterativ treffen
  • Entscheidungen mit großer Tragweite sehr gut dokumentieren
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

Wie garantieren Architekten die Machbarkeit von Anforderungen?

A
  • Durch Prototypen (PoC), Framework testen, Performancetests
  • Dafür sorgen das funktionale und nichtfunktionale Anforderungen eingehalten werden
  • Einen angemessenen Kostenrahmen einhalten (Lizenzen)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

Wen beraten Architekten?

A
  • Management und Auftraggeber für Planung/Organisation
  • Auftraggeber zu Machbarkeit, Kosten, Realisierung, Betrieb
  • Projektleiter bei Steuerung des Implementierungsteams
  • Implementierungsteam bei Umsetzung
  • Qualitätssicherung zu Testbarkeit und Bewertung
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

Sollten Architekten Kosten für ein Projekt genau abschätzen können?

A

Nein, aber zumindest eine Größenordnung oder Hausnummer sollte planbar sein.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

Woran sollte das Ausmaß einer Dokumentation gemessen sein?

A

Wer es lesen soll.

  • Manchmal reicht eine Skizze am Kaffeetisch
  • Manchmal eine ausführliche API Dokumentation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Was sollten Projekte immer bleiben?

A
  • Agil
  • Flexibel
  • Kurzfristig wandelbar
    (Architekten sind verantwortlich ob dies möglich ist)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

Was sind die Anforderungen an ein Projekt?

A

Anforderungen müssen immer abgewägt werden. (Performance gegen Wartbarkeit etc)

Es gibt keine Architektur die sehr günstig, performant, flexibel und wartbar ist.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

Wie müssen Architekten kommunizieren?

A
  • Architekturen für verschiedene Stakeholder unterschiedlich aufbereiten
  • Stakeholder das Konzept verkaufen
  • Team coachen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

Was sind die Werkzeuge eines Architekten?

A
  • Modelle: Zeigen nie das große Ganze in allen Details
    (Alle Modelle sind falsch, aber meist hilfreich)
  • System-Dokumentationen
  • Erfahrungen, Regeln
  • Muster (Lösungen zu bestimmten Problemen)
  • Partition und Aggretation von Problemen
  • Iteratives Vorgehen (Sehr wichtig!) Nicht nur wasserfallmäßig linear arbeiten
    *
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

Was ist Conways Law?

A

Das Gesetz von Conway basiert auf der Überlegung, dass für die Definition der Schnittstellen zwischen getrennten Softwaremodulen zwischenmenschliche Kommunikation notwendig ist. Daher haben die Kommunikationsstrukturen der Organisationen einen großen Einfluss auf die Strukturen dieser Schnittstellen

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Wie sieht ein Architekten-Team am besten aus?

A
  • Ein eher kleines Team (Nicht alleine)
  • Erfahrungen in Softwareentwicklung vorhanden
  • Erfahrungen in Fachbereich vorhanden!
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

Wie sieht ein iterativer Ansatz in der Softwarearchitektur aus?

A
  • Man trifft immer wieder eine Entscheidung und driftet in eine Richtung ab.
  • Durch die getroffene Entscheidung wird man in der neuen Richtungsauswahl eingeschränkt
  • Wenn man alles richtig gemacht hat, ist man am Ende nicht am Ziel der Planung sondern da wo der Kunde wirklich hin wollte (es nur nicht wusste)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

Was sollte Softwarearchitektur organisatorisch nicht entstehen?

A
  • Nur an bestimmten Tagen/Zeitpunkten Entscheidungen treffen und nicht kontinuierlich
  • Abkapseln und im stillen Kämmerlein arbeiten
  • Nur auf Marketing fokusiert sein
  • Sich nur am Namen der Architektur festmachen. (Wir machen React)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

Ist der Beruf Softwarearchitekt ein Status?

A

Nein, das sollte er nicht sein.
Gute Architekten sind sehr gute Softwareentwickler mit gutem Überblick, die Menschen führen können und Wissen über das System haben.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

In welchem Kontext steht Softwarearchitektur im Unternehmen bzw mit was steht es alles im Kontakt.

A
  • Projektplanung
  • Qualitätssicherung
  • Betrieb
  • Hardwareentwicklung
  • Designs/Implementierung
  • Risikoanalyse
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

Woher stammt der Begriff Architektur?

A
  • Aus dem Mittelalter für Baustil/Baukunst
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

Was sind die Ziele von Architektur?

A
  • Erfahrungen und Wissen verallgemeinern
  • Ordnung und Verallgemeinerung von strukturellen Beziehungen im Bauwesen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

Zitate

A
  • The software architecture of deployed software is determined by those aspects that are the hardest to change
  • Das Leben von Software-Architekten besteht auf einer langen und schnellen Abfolge suboptimaler Entwurfsentscheidungen, die meist im Dunkel getroffen werden
  • Die zuverlässigste, preiswerteste und robusteste Komponente eines Systems ist diejenige, die erst gar nicht realisiert werden muss
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

Woraus besteht Architektur?

A
  • Bausteine/Komponenten des Systems
  • Wesentliche extern sichtbare Eigenschaften der Bausteine
  • Beziehungen zwischen den Bausteinen/Komponenten untereinander
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q

Auf welchen Entwurfsentscheidungen basiert Architektur?

A
  • Entscheidungen zum Entwurf der Komponente
  • Entscheidungen für Technologien
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

Was tut eine Sicht der Architektur?

A
  • Dokumentiert Aspekte eines Gesamtsystems
  • Ist nützlich für einen bestimmten Stakeholder
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

Warum ist Architektur Abstraktion?

A
  • Weil die Aufgabe von Architekten das Weglassen von nicht benötigten Informationen ist
  • Diese werden bewusst gefiltert, um Darstellungen verständlich zu halten
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

Wo ist der Unterschied zwischen Architektur und Entwurf/Design?

A
  • Fließende Grenze
  • Design/Entwurf ist der Prozess der Erstellung von Architektur
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
54
Q

Wie beraten Architekten?

A
  • Management und Auftraggeber bei Projektplanung
  • Auftraggeber zu Machbarkeit, Kosten, Anforderungen, Betrieb
  • Projektleiter bei Organisation und Steuerung des Implementierungsteams
  • Projektleiter bei Risikomanagement
  • Hardwarearchitekten bei Hardwareanforderungen
  • Qualitätssicherung bei Testbarkeit von Systemen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
55
Q

Wie dokumentieren Architekten?

A
  • Nach den Bedürfnissen der Adressaten
  • Pragmatisch (Manchmal reicht eine Skizze auf einem Umschlag)
  • So das Projekte, agil, flexibel und kurzfristig bleiben
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
56
Q

Wie bewerten Architekten?

A
  • Wann sind nicht funktionale Anforderungen riskant oder kritisch?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
57
Q

Seit wann gibt es den Begriff Softwarearchitektur?

A
  • In einer Natokonferenz in Rom 1980 ist der Begriff das erste Mal aufgetreten.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
58
Q

Warum ist der Begriff Softwarearchitektur enstanden?

A
  • Nach 1960 wurden System so komplex, dass ein einzelner nicht mehr alle Infos wissen konnte und Teams daran arbeiten mussten.
  • In Systemen wurde die Software teurer als die Hardware und Projekte verzögerten sich immer mehr und wurden viel teurer als angenommen.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
59
Q

Was machen Mainframes heute?

A
  • Verarbeiten 80% aller Unternehmensdaten mit 30 Mrd Transaktionen pro Tag
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
60
Q

Wann entstanden die ersten Softwarearchitekturen?

A
  • Dekomposition, Zerlegung, Entwurf:
    1970er Jahre mit The Mythical Man Month
  • Schnittstellen und Konnektoren:
    1990er Jahre mit Software Architecture Analysis Method
  • Anwendung und Verbreitung:
    2000er Jahre mit IEEE Standards, UML 2.0
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
61
Q

Was waren Pioniere der Softwarearchitektur?

A
  • Davis Parnas
  • Frederick Brooks
  • Tony Hoare
  • Edsge Dijkstra
  • Per Brinch Hansen
  • Friedrich Bauer
  • Niklaus Wirth
    *
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
62
Q

Was hat David Parnas erfungen?

A
  • Geheimnisprinzip
  • Grundlagen OOP
  • Modulkonzept
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
63
Q

Was hat Frederick Brooks erfunden?

A
  • Schrieb das erste ehrliche Buch über Softwareentwicklung:
    The Mystical Man Month, Essays über Software Engineering
  • Brooks Law:
    Adding Manpower to a late software project makes it later
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
64
Q

Was hat Tony Hoare erfungen?

A
  • Quicksort Algorithmus
  • Hoare-Kalkül zum Beweisen von Algorithmen
  • Grundlage der Programmiersprachen Ada, Occam und Go
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
65
Q

Was hat Edsge Dijkstra erfunden?

A
  • Dijkstra Algorithmus zum Berechnen des kürzesten Weges in einem Graphen
  • Semphoren für Synchronisation von Threads
  • Erstes Betriebssystem mit Schichtenarchitektur
  • Prägte Begriffe der strukturierten Programmierung der Softwarekrise
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
66
Q

Was hat Per Brinch Hansen erfunden?

A
  • Erste Implementierung des Mikrokernkonzepts
  • Monitorkonzept für paralelle Programmierung
  • Erste parallele Programmiersprache
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
67
Q

Was hat Friedrich Bauer erfunden?

A
  • Stack-Konzept (Kellerspeicher) erfunden
  • Hielt die erste Informatikvorlesung in DE
  • Autor in Kryptologie
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
68
Q

Was hat Niklaus Wirth erfunden?

A
  • Wirthsche Gesetz:
    Software verlangsamt sich schneller, als Hardware sich beschleunigt
  • Programmiersprache PL360 für IBM Mainframes
  • Programmiersprache Pascal
  • Erweiterte Backus Nauer Form als formale Sprache
  • Computermaus import, der Logitech gründete
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
69
Q

Was erkennt man an der Entwicklung des Linux Kernels und Ruby on Rails?

A
  • Die Komplexität von Software hat über die Jahre immer weiter zugenommen
  • LInes Of Code, Klassen, Methoden stiegen stark an
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
70
Q

Warum braucht man Sichten?

A
  • Eine Darstellung alleine kann alle Komplexitäten für alle Perspektiven ausdrücken (Grundriss reicht nicht für Hausbau)
    *
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
71
Q

Was müssen Architekten den Projektbeteiligten erklären?

A
  • Entworfene Strukturen
  • Getroffene Entscheidungen
  • Konzepte, Begründungen, Vorteile, Nachteile
  • Mit den verschiedenen Sichten viele Aspekte verständlich darstellen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
72
Q

Wie lautet der Kreislauf in dem Architekten in einem Team für gemeinsames Verständnis sorgen?

A

->
Anforderungen klären ->
Entwerfen ->
kommunizieren ->
Bewerten ->

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
73
Q

Wie heißen die 4 Sichten der Softwarearchitektur?

A
  • Kontextabgrenzung
  • Laufzeitsicht
  • Bausteinsicht
  • Verteilungssicht
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
74
Q

Was beschreibt die Kontextabgrenzung (kurz)?

A
  • Vogelperspektive & Nachbarsysteme
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
75
Q

Was beschreibt die Laufzeitsicht (kurz)?

A
  • Wie arbeiten Bausteine zusammen?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
76
Q

Was beschreibt die Bausteinsicht (kurz)?

A
  • Statische Struktur von Bausteinen und Beziehungen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
77
Q

Was beschreibt die Verteilungssicht (kurz)?

A
  • In welchem Umgebungen läuft es ab?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
78
Q

Was zeigt die Kontextsicht?

A
  • Wie System in Umgebung eingebettet ist
  • Zeigt System als Blackbox im Kontext aus Vogelperspektive
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
79
Q

Welche Informationen enthält die Kontextsicht?

A
  • Schnittstellen zu Nachbarsystemen
  • Interaktionen mit Stakeholdern
  • Teile der Infrastruktur
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
80
Q

Wie sehen Beispiele für die Kontextsicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
81
Q

Wie sehen Beispiele für die Kontextsicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
82
Q

Wie sehen Beispiele für die Kontextsicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
83
Q

Wie sehen Beispiele für die Kontextsicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
84
Q

Was zeigt die Bausteinsicht und wem hilft es?

A
  • Wie ist ein System intern aufgebaut?
  • Hilft einem Auftraggeber und Projektleiter bei Projektüberwachung
  • Hilft bei Arbeitspaketzuteilung
  • Referenz für Softwareentwickler
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
85
Q

Welche Informationen enthält die Bausteinsicht?

A
  • Statische Strukturen der Bausteine eines Systems
  • Subsysteme
  • Komponenten und Schnittstellen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
86
Q

Wie sehen Beispiele für die Bausteinsicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
87
Q

Wie sehen Beispiele für die Bausteinsicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
88
Q

Wie sehen Beispiele für die Bausteinsicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
89
Q

Wie sehen Beispiele für die Bausteinsicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
90
Q

Was zeigt die Bausteinsicht?

A
  • Wie das System abläuft
  • Welche Beusteine zur Laufzeit existieren
  • Wir wirken die Bausteine zusammen?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
91
Q

Wie sehen Beispiele für die Laufzeitsicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
92
Q

Wie sehen Beispiele für die Laufzeitsicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
93
Q

Wie sehen Beispiele für die Laufzeitsicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
94
Q

Wie sehen Beispiele für die Laufzeitsicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
95
Q

Was zeigt die Verteilungssicht?

A
  • In welcher Umgebung läuft das System ab?
  • Zeigt es aus Betreibersicht
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
96
Q

Welche Informationen enthält die Verteilungssicht?

A
  • Hardwarekomponenten(Rechner, Prozessoren)
  • Netzprotrokolle/Netztopologien
  • Physische Bestandteile der Systemumgebung
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
97
Q

Wie sehen Beispiele für die Verteilungssicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
98
Q

Wie sehen Beispiele für die Verteilungssicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
99
Q

Wie sehen Beispiele für die Verteilungssicht aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
100
Q

Gibt es weitere Sichten außer den 4?

A
  • In der Literatur findet man noch ein paar, jedoch sind das meist nur abgewandelte Sichten ohne Mehrwert.
  • Man sollte darauf verzichten mehr zu benutzen
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
101
Q

Warum sollte man auf weitere Sichten verzichten?

A
  • Zusätzlicher Erstellungs- und Wartungsaufwand.
  • Grundlegende Aspekte werden bereits durch die 4 abgedeckt.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
102
Q

Was ist ein Beispiel einer sehr speziellen und meist nicht nützlichen “Sicht”?

A
  • Karte über Lichteinfall in die Wohnung, ist für Pflanzenzüchter interessant, aber für wenig andere sonst.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
103
Q

Gibt es noch weitere Sichtenmodelle in der Literatur?

A
  • Ja
  • 4+1 Sicht
  • Modulstandpunkt

-> Im Endeffekt sind alle keine Neuerfindungen des Rades, sondern abgeänderte Kopien.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
104
Q

Wie sollten Sichten entstehen?

A
  • Entwurf von Sichten hat Abhängigkeiten
  • Software sollte iterativ entstehen da manche Auswirkungen erst über Grenzen von Sichten spürbar sind
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
105
Q

Welche Sichten haben untereinander Wechselwirkungen?

A
  • Jede Sicht hat mit jeder Sicht eine Wechselwirkung
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
106
Q

In welcher Reihenfolge sollte man Sichten erstellen?

A
  • Oftmals parallel erstellt und verbessert
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
107
Q

Wann sollte man die Bausteinsicht zuerst erstellen?

A
  • Bei Erstellung eines ähnlichem Systems mit Vorstellung von benötigten Komponenten
  • Ein bestehendes System ändern muss und Teile der Sicht vorgegeben sind
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
108
Q

Wann sollte man die Laufzeitsicht zuerst erstellen?

A
  • Bei Vorstellungen von wesentlichen Bausteinen und man möchte die Verantwortlichkeit und Zusammenspiel klären
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
109
Q

Wann sollte man die Verteilungssicht zuerst erstellen?

A
  • Bei vielen Randbedingungen und Vorgaben durch technische Infrastruktur, Rechenzentrum oder Admins
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
110
Q

Wieviel Aufwand fließt in welche Sicht?

A
  • 60-80% der Zeit für die Sichten wird in die Bausteinsicht fließen, da sie viel detailliert ausgeführt wird als die anderen Sichten
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
111
Q

Sollte man nur die Bausteinsicht erstellen und die anderen Sichten vernachlässigen?

A
  • Nein, man sollte auf jeden Fall alle Sichten erstellen
  • Das ist für das Gesamtprojekt wichtig und für verschiedene Stakeholder
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
112
Q

Sollte man Entwurfsentscheidungen und Beschreibungen die Sichten beeinflussen dokumentieren?

A
  • Ja, z.B. eine zentrale Datenhalung ist noch wichtig für den weiteren technischen Verlauf der Infrastruktur
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
113
Q

Was sind die Vorteile wenn man Wechselwirkungen der Sichten dokumentiert?

A
  • Bessere Nachvollziehbarkeit von Entscheidungen
  • Änderungen werden vereinfacht
  • Zusammenhänge und Übersicht der Architektur wird besser
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
114
Q

Wie entwirft man die Sicht Kontextabgrenzung?

A
  • Ist Ergebnis der Anforderungsanalyse
  • Zeigt sämtliche Nachbarsysteme
  • Alle Ein/Ausgehenden Daten und Ereignisse müssen erkennbar sein
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
115
Q

Wie entwirft man die Bausteinsicht?

A
  • Bausteinsicht ist Kern der Architekturbeschreibung
  • Man beschreibt exakt wie das System strukturell aufgebaut ist
  • Zuerst beginnt man mit der Vogelperspektive der Implementierungsbausteine
  • Man zerelgt ein System in große Elemente wie Teilsysteme
  • 60-80% der Arbeit!
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
116
Q

Wie entwirft man die Laufzeitsicht?

A
  • Die Elemente der Laufzeitsicht sind Elemente für die Bausteinsicht
  • Daher kann man die Bausteinsicht für die Erstellung der Laufzeitsicht nutzen
  • Man beschreibt die Dynamik der statischen Bausteine und beginnt bei den wichtigsten Use-Cases des Gesamtsystems.
  • Man kann auch von der Verteilungssicht starten
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
117
Q

Wie entwirft man die Verteilungssicht?

A
  • Verteilungssicht ist eine Landkarte der Hardware und externen Systemen
  • Genügen die verfügbare Hardware, Kommunikationskanäle, gibt es Engpässe?
  • Falls ein System verteilt laufen soll müssen Kommunikationsmechanismen, Protokolle und Middleware in die Infrastruktursicht aufgenommen werden.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
118
Q

Was ist Qualität?

A
  • Beschaffenheit, Güte, Wert
  • Wenn der Kunde wiederkommt nicht das Produkt
  • DIN/ISO Norm die es genau spezifiziert (Funktionalität, Zuverlässigkeit, Benutzbarkeit, Effizienz etc)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
119
Q

Wie sieht das magische Dreieck der Qualität aus?

A
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
120
Q

Was sind die Probleme mit Qualität?

A
  • Qualität ist nur indirekt messbar
  • Qualität ist relativ und subjektiv, für jeden Betrachter anders
  • Qualität von Architektur ist nicht notwendigerweise Codequalität
  • Erfüllung aller funktionalen Anforderungen heißt nicht Erfüllung von Qualität
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
121
Q

Beispiel funktionale Anforderungen anhand von Sortieren von Daten:

A
  • Funktional kann es erfüllt sein, aber nicht funktional?
  • Was ist bei:
    Große Datenmengen (TB)?
    Sonderzeichen?
    Parallele Benutzer?
    Sortierung anhaltbar?
    Erweiterbarkeit?
    Entwicklung mit verteilten Teams?
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
122
Q

Welche Qualitätsmerkmale hält der DIN/ISO 9126 Norm fest?

A
  • Funktionalität:
    Satz von Funktionen mit spezifizierten Eigenschaften
  • Zuverlässigkeit:
    Fähigkeit, Leistungsniveau konstant über Zeitraum
  • Benutzbarkeit:
    Aufwand zur Benutzung
  • Effizienz:
    Leistung im Gegensatz zu eingesetzte Betriebsmittel
  • Änderbarkeit:
    Aufwand für Änderungen
  • Übertragbarkeit:
    Eignung zur Übertragung in andere Umgebung
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
123
Q

Was sind Architekturmuster?

A
  • Muster für Softwarearchitekturen die erprobte Generallösungen für wiederaufkehrende Probleme beschreiben. Die Lösung beschreibt Komponenten und Beziehungen.
  • Bewährte Lösung für ein wiederholt auftretendes Entwurfsproblem
  • Ein Architekturmuster definiert den Kontext für die Anwendbarkeit der Lösung
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
124
Q

Warum gibt es Architekturmuster?

A
  • Erfolg -> Weisheit, Weisheit -> Erfahrung, Erfahrung -> Fehlern.
  • Dummer Fehler zwei Mal gemacht? Reale Welt, Hundert Mal gemacht? Softwareentwicklung
  • Aus Fehlern kann man gut lernen, aber kaum Kunden akzeptieren Fehler
    *
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
125
Q

Was sind Heuristiken im Kontext der Architekturmuster?

A
  • Heuristiken sind Abstraktionen von Erfahrungen anderer Architekten und Projekte
  • Heuristiken sind Regeln zur Behandlung von komplexen Problemen für die es viele Lösungen gibt, indem sie Komplexität reduzieren.
  • Heuristiken sind Regeln, Muster, Prinzipien, es sind abstrakte Verallgemeinerungen.
  • Heurisitiken bieten Orientierung wie Wegweise oder Straßenschilder, die Verantwortung, Auswahl und Umsetzung bleibt bei einem selbst.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
126
Q

Worin liegt die Kunst der Architektur in Zusammenhand mit Heuristiken?

A
  • Bei der Weisheit die passende Heuristik für das aktuelle Projekt zu wählen.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
127
Q

Was ist der klassische Ansatz zur Lösung von Problemen in der Architektur?

A
  • Teile und Herrsche
  • Das unlösbare Problem in immer kleinere Teilprobleme zerlegen, bis man diese lösen kann.
128
Q

Was sind klassische Architekturmuster?

A
  • Horizontale Zerlegung: “In Scheiben schneiden”
  • Vertikale Zerlegung: “In Stücke schneiden”
129
Q

Was ist die horizontale Zerlegung?

A
  • Jede Schicht stellt klar definierte Schnittstellen zur Verfügung und nutzt Dienst von unterliegenden Schichten
  • Ein klassiches Architekturmuster
130
Q

Was ist die vertikale Zerlegung?

A
  • Jeder teil übernimmt eine bestimmte fachliche oder technische Funktion
  • Ein klassisches Architekturmuster
131
Q

Was ist das Muster der Kapselung(Information Hiding?)

A
  • Kapselung von Komplexität in Komponenten
  • Betrachtung von Komponenten als Black Box
  • Definition klarer Schnittstellen
132
Q

Was passiert bei einer Zerlegung ohne Kapselung?

A
  • Das Problem wird erschwert und nicht vereinfacht. Kapselung ist nötig.
133
Q

Was ist das Muster der Wiederverwendung?

A
  • Wiederverwendbarkeit verringert Wartungsaufwand
    (Nur sinnvolle Dinge wiederverwenden!)
134
Q

Was ist der iterative Entwurf?

(Prinzip zum Zerlegen)

A
  • Überprüfen eines Entwurfs mit Prototypen oder Durchstichen
  • Auswertung von Stärken und Schwächen des Entwurfs
  • Bewertung und Analyse der Versuche
135
Q

Was ist die Dokumentation von Entscheidungen?

(Prinzip zum Zerlegen)

A
  • Warum wurden Entscheidungen so getroffen?
  • Welche Alternative wurden bewertet?
  • Andere Beteiligte werden Entscheidungen später kritisieren.
136
Q

Was ist die Unabhängigkeit der Elemente?

(Prinzip zum Zerlegen)

A
  • Geringe Abhängigkeit zwischen Elementen
  • Wartbarkeit und Flexibilität des Systems wird erhöht
  • Komponenten machen keine Annahmen über andere Komponenten
137
Q

Was ist REST?

A
  • Representational State Transfer
  • Programmierparadigma für verteile Systeme wie Webservices
  • Abstraktion des WWW
138
Q

Was ist das Ziel von REST?

A
  • Rest möchte einen Architekturstil schaffen, der die Anforderungen des modernen Webs besser darstellt.
139
Q

Wie funktioniert REST?

A
  • Zweck ist Maschine zu Maschine Kommunikation
  • Rest kodiert Methodeninfos in die URI, welche Ort und Namen der Ressource angibt.
  • Ressource kann über verschiedene Medientypen(Repränsentationen) dargestellt werden
140
Q

Nenne die REST Prinzipien!

A
  • Client-Server
  • Zustandslos
  • Caching
  • Einheitliche Schnittstellen
  • Mehrschichtiges System
  • Code on Demand
141
Q

Was wird durch REST erreicht?

A
  • Addressierbarkeit von Ressourcen
  • Repräsentation von veränderten Ressourcen
  • Selbstbeschreibende Nachrichten über HTTP
142
Q

Was ist HTTP?

A
  • Hypertext Transfer Protocol (HTTP)
  • Zustandsloses Protokoll zur Übertragung von Daten auf Anwendungsschicht
  • Zum laden von WWW Webseiten
  • Auch nur zum laden von Daten nutzbar
143
Q

Was sind HTTP Verben?

A
  • GET
  • POST
  • PUT
  • PATCH
  • DELETE
144
Q

Was macht das HTTP Verb GET?

A
  • GET fordert eine angegebene Ressource vom Server an
145
Q

Was macht das HTTP Verb POST?

A
  • POST fügt eine neue Ressource unterhalb der angegebenen Resssource ein.
146
Q

Was macht das HTTP Verb PUT?

A
  • PUT legt eine Ressource an oder ändert eine bestehende.
147
Q

Was macht das HTTP Verb PATCH?

A
  • PATCH ändert einen Teil einer Ressource.
148
Q

Was macht das HTTP Verb DELETE?

A
  • DELETE löscht die angegebene Ressource.
149
Q

Welche Arten von Kategorien für Architekturmuster gibt es?

A
  • Chaos zu Struktur
  • Verteile Systeme
  • Interaktive Systeme
  • Adaptive Systeme
  • Domain-spezifische Architekturen
150
Q

Welche Architekturmuster gehören
zur Kategorie
Chaos zu Struktur?

A
  • Layers
  • Pipes and Filter
  • Blackboard
  • Domain-Driven Design
151
Q

Was sind Eigenschaften
von Architekturmuster der
Chaos zur Struktur Kategorie?

A
  • Organisation der Komponenten und Objekte eines Systems
  • Funktionalität wird in kooperierende Subsysteme aufgeteilt
  • Zu Beginn des Entwurfs werden Anforderungen analysiert
  • Berücksichtung von:
    Integrierbarkeit
    Wartbarkeit
    Änderbarkeit
    Portierbarkeit
    Skalierbarkeit
152
Q

Was sind Eigenschaften
von Architekturmuster der
Verteilte Systemen Kategorie?

A
  • Verteilung von Ressourcen und Diensten im Netzwerk
  • Kein zentrales System mehr
  • Gute Infrastruktur lokaler Netze
153
Q

Welche Architekturmuster gehören
zur Kategorie
Verteilte Systeme?

A
  • Serviceorientierte Architektur
  • Peer to Peer
  • Client Server
154
Q

Was sind Eigenschaften
von Architekturmuster der
Interaktive Systeme Kategorie?

A
  • Strukturierung von Mensch-Computer-Interaktionen
  • Gute Schnittstellen für Benutzer
  • Systemkern bleibt unangetastet von Benutzereingaben
155
Q

Welche Architekturmuster gehören
zur Kategorie
Interaktive Systeme?

A
  • Model View Controller (MVC)
  • Model View Presenter
  • Presentation Abstraction Control (PAC)
156
Q

Was sind Eigenschaften
von Architekturmuster der
Adaptive Systeme Kategorie?

A
  • Unterstützung der Erweiterung und Anpassungsfähigkeit von Systemen
  • Das System soll für Erweiterungen offen sein
  • Kernfunktionalitäten sollen unberührt bleiben
157
Q

Welche Architekturmuster gehören
zur Kategorie
Adaptive Systeme?

A
  • Mikrokernel
  • Reflexion
  • Dependency Injection
158
Q

Was sind Anti-Patterns?

A
  • Schlechte Lösungsmuster für bestimmte Probleme
  • Das Gegenteil eines Architekturmusters, aus dem man trotzdem lernen kann
159
Q

Welche 4 Kategorien für Anti-Pattern gibt es?

A
  • Projektmanagement Anti-Pattern
  • Architektur Anti Pattern
  • Code Smells
  • Organisations Anti Pattern
160
Q

Was sind Anti-Pattern
der Kategorie
Projektmanagement?

A
  • Blendwerk
  • Aufgeblähte Software
  • Feature Creep
  • Scrope Creep
  • Brooksches Gesetz
  • Death Sprint
  • Death March
161
Q

Was sind Anti-Pattern
der Kategorie
Architektur?

A
  • Big Ball of Mud
  • Gasfabrik
  • Gottobjekt
  • Innere-Plattform-Effekt
  • Spaghetticode
  • Sumo-Hochzeit
162
Q

Was sind Anti-Pattern
der Kategorie
Code Smells?

A
  • Zwiebel
  • Copy and Paste
  • Lavafluss
  • Magische Werte
  • Reservierte Wörter
  • Unbeabsichtigte Komplexität
163
Q

Was sind Anti-Pattern
der Kategorie
Organisation?

A
  • Wunderwaffe
  • Das Rad neu erfinden
  • Das quadratische Rad neu erfinden
  • Body Ballooning
  • Empire Building
  • Warme Leiche
  • Single Head of Knowledge
164
Q

Was sind weitere Anti-Pattern
der Kategorie
Organisation?

A
  • Management nach Zahlen
  • Vendor Lock-In
  • Design By Committee
  • Boat Anchor
  • Dead End
  • Swiss Army Knife
165
Q

Was beschreibt das Anti-Pattern Blendwerk
und welcher Kategorie gehört es an?

A
  • Nicht fertige Funktionen werden als fertig dargestellt
  • Gehört zu Projektmanagement
166
Q

Was beschreibt das Anti-Pattern Aufgeblähte Software
und welcher Kategorie gehört es an?

A
  • Bloatware meint, dass Software mit Funktionen überladen ist.
  • Software ist für Benutzer unübersichtlich und für Entwickler schwer wartbar
  • Gehört zu Projektmanagement
167
Q

Was beschreibt das Anti-Pattern Featurecreep
und welcher Kategorie gehört es an?

A
  • Feature Creep bezeichnet es wenn Software ständig neue Anforderungen dazu bekommt.
  • Termine werden nicht eingehalten und Kosten steigen rasant
  • Gehört zu Projektmanagement
168
Q

Was beschreibt das Anti-Pattern Scope Creep
und welcher Kategorie gehört es an?

A
  • Anwendungsbereiche werden ständig erweitert.
  • Termine werden nicht eingehalten und Kosten steigen rasant.
  • Gehört zu Projektmanagement
169
Q

Was beschreibt das Anti-Pattern Deathsprint
und welcher Kategorie gehört es an?

A
  • Ein Deathsprint ist iterative Software, die viel zu kurze Zeitspannen hat.
  • Nach außen gibt es viele Releases und Versionen, aber die Qualität der Software nimmt mit jedem “erfolgreichen” Release ab.
  • Gehört zu Projektmanagement
170
Q

Was beschreibt das Anti-Pattern Death March
und welcher Kategorie gehört es an?

A
  • Beim Deathmarch zieht sich ein Projekt ewig hin.
  • Kann auch bewusst gemacht werden um von Defiziten im Unternehmen abzulenken.
  • Man entwickelt solange vor sich hin, bis zwar nicht die Spezifikation eingehalten ist, aber es irgendwie als funktioniert bezeichnet werden kann.
  • Gehört zu Projektmanagement
171
Q

Wie lautet das Brooksche Gesetz?

A
  • Adding manpower to a late software project makes it later
172
Q

Was beschreibt das Anti-Pattern Big Ball of Mud
und welcher Kategorie gehört es an?

A
  • Wenn eine Software keine Architektur besitzt.
  • Durch wenig Erfahrung, Bewuststein und Druck entsteht ein Ball aus Abhängigkeiten.
  • Gehört zu Architektur
173
Q

Was beschreibt das Anti-Pattern Gasfabrik
und welcher Kategorie gehört es an?

A
  • Die Gasfabrik sind zu komplexe Entwürfe für simple Probleme
  • Gehört zu Architektur
174
Q

Was beschreibt das Anti-Pattern Gottobjekt
und welcher Kategorie gehört es an?

A
  • Das Gottobjekt hat zentral den Großteil der Verantwortlichkeiten während die anderen Elemente nur Daten speichern oder anbieten.
  • Gehört zu Architektur
175
Q

Was beschreibt das Anti-Pattern Innere-Plattform-Effekt
und welcher Kategorie gehört es an?

A
  • Der Innere Plattform Effekt tritt auf wenn ein System so konfigurierbar wird, dass ein eine Kopie der Plattform wird mit der es gebaut wurde.
  • Datenmodell verzichtet auf Datenbanktabelle und baut sie dann selber nach.
  • Gehört zu Architektur
176
Q

Was beschreibt das Anti-Pattern Spaghetti Code
und welcher Kategorie gehört es an?

A
  • Spaghetti Code ensteht durch unstrukturierten Code ohne Objekorientierung oder Kontrolfluss
  • Gehört zu Architektur
177
Q

Was beschreibt das Anti-Pattern Sumo-Hochzeit
und welcher Kategorie gehört es an?

A
  • Sumo-Hochzeit ist wenn z.B. viel Logik in PLSQL Datenbankprogrammiersprache ist.
  • Die Architektur wird dadurch sehr inflexibel
  • Gehört zu Architektur
178
Q

Was beschreibt das Anti-Pattern Zwievel
und welcher Kategorie gehört es an?

A
  • Bei der Zwiebel werden neue Funktionalitäten um alte als Schicht gehüllt.
  • Oft wenn man Software weiterentwickelt die man nicht selber geschrieben hat und nicht alles versteht.
  • Gehört zu Code Smells
179
Q

Was beschreibt das Anti-Pattern Cut-and-Paste Programmierung
und welcher Kategorie gehört es an?

A
  • Code wird redundant wiederverwendet
  • Sorgt für Wartungsprobleme
  • Lösung durch Refactoring
  • Gehört zu Code Smells
180
Q

Was beschreibt das Anti-Pattern Lavafluss
und welcher Kategorie gehört es an?

A
  • Im Lavafluss liegt immer mehr toter Quellcode herum, Code wird drumherum oder hindurch geschrieben.
  • Gehört zu Code Smells
181
Q

Was beschreibt das Anti-Pattern Wunderwaffe
und welcher Kategorie gehört es an?

A
  • Eine Wunderwaffe wird für alle Probleme genutzt. Man kennt nur Nägel.
  • Gehört zu Organisation
182
Q

Was beschreibt das Anti-Pattern Das Rad neuerfinden
und welcher Kategorie gehört es an?

A
  • Beim Rad neu erfinden verschendet man Geld und Zeit anstatt vorhanden Lösungen zu nutzen.
  • Gehört zu Organisation
183
Q

Was beschreibt das Anti-Pattern quadratische Rad neu erfinden
und welcher Kategorie gehört es an?

A
  • Man erfindet eine schlechte Lösung neu, obwohl eine gute besteht.
  • Gehört zu Organisation
184
Q

Was beschreibt das Anti-Pattern Body ballooning
und welcher Kategorie gehört es an?

A
  • Body Ballooning ist wenn ein Vorgesetzter nur seine Macht erweitern möchte.
  • Daher zieht er evtl Arbeitsintensive Methoden den effizienten vor.
  • Gehört zu Organisation
185
Q

Was beschreibt das Anti-Pattern Empire Building
und welcher Kategorie gehört es an?

A
  • Ähnlich wie Body Ballooning kann aber auch durch dauernde Anschuldigungen anderer geschehen.
  • Ex-Mitarbeiter wird die Schuld zu geschoben.
  • Gehört zu Organisation
186
Q

Was beschreibt das Anti-Pattern Warme Leiche
und welcher Kategorie gehört es an?

A
  • Eine warme Leiche ist eine Person die keinen Beitrag mehr zum Projekt leitet.
  • Gehört zu Organisation
187
Q

Was beschreibt das Anti-Pattern Single Head of Knowledge
und welcher Kategorie gehört es an?

A
  • Wenn das Wissen des Unternehmens in einem Kopf steckt.
  • Zu wenig Austausch zwischen Kollegen, kann auch angestrebt werden.
  • Gehört zu Organisation
188
Q

Was beschreibt das Anti-Pattern Management nach Zahlen
und welcher Kategorie gehört es an?

A
  • Management nach Zahlen ist wenn Fokus auf Kosten gelegt wird anstatt Qualität.
  • Gehört zu Organisation
189
Q

Was beschreibt das Anti-Pattern Vendor Lockin
und welcher Kategorie gehört es an?

A
  • Beim Vendor Lockin hängt man am einer proprietären Architektur, Hersteller etc fest.
  • Gehört zu Organisation
190
Q

Was beschreibt das Anti-Pattern Design By Comittee
und welcher Kategorie gehört es an?

A
  • Design By Comittee ist wenn man es jedem recht machen möchte und es zu komplex wird.
  • Gehört zu Organisation
191
Q

Was beschreibt das Anti-Pattern Boat Anchor
und welcher Kategorie gehört es an?

A
  • Boat Anchor ist eine Komponente ohne Nutzen
  • Gehört zu Organisation
192
Q

Was beschreibt das Anti-Pattern Dead End
und welcher Kategorie gehört es an?

A
  • Dead End ist wenn eine eingekaufte Komponente nicht mehr unterstützt wird.
  • Gehört zu Organisation
193
Q

Was beschreibt das Anti-Pattern Swiss Army Knife
und welcher Kategorie gehört es an?

A
  • Swiss Army Knife is wenn eine Komponente vorgibt alles zu können.
  • Gehört zu Organisation
194
Q

Was ist das Layers Muster?

A
  • Layers Muster trennt Architektur in Schichten bei den jede eine Unteraufgabe auf Abstraktionsebene realisiert.
  • Jede Schicht schützt die unteren Schichten vor direkten Zugriff durch höhere Schichten.
195
Q

Für was ist das ISO/OSI Modell ein Beispiel?

A
  • Für das Layers-Schichten Muster
  • In 7 Schichten aufgeteilt
  • Jede Schicht andere Aufgabe
196
Q

Was sind Ziele beim Layers-Schichen Muster?

A
  • Änderungen am Quellcode sollten wenig Ebenen betreffen
  • Schnittstellen stabil sein
  • Ebenen separat und austauschbar sein
197
Q

Was sind Top-Down Anforderungen als dynamisches Verhalten des Layers-Schichten Muster?

A
  • Anforderungen von Benutzer werden von oberster Schicht angenommen.
  • Anforderungen werden durch die Schichten nach unten geschickt.
198
Q

Was sind Bottom-Up Anforderungen als dynamisches Verhalten des Layers-Schichten Muster?

A
  • Die unterste Schicht empfängt das Signal und schickt es an die obersten weiter.
  • Die oberste Schicht sendet es an Benutzer.
199
Q

Was sind Protokoll Stack Anforderungen als dynamisches Verhalten des Layers-Schichten Muster?

A
  • Zwei n-Schichten Stacks kommunizieren miteinander.
  • Anforderung geht durch den ersten Stach runter und wird von zweiten Stack empfangen.
  • Jeder Stack hat sein eigenes Protokoll.
    (Beispiel TCP/IP)
200
Q

Was sind die Vorteile von Layers-Muster?

A
  • Wiederverwendung und Austauschbarkeit von Schichten
  • Einkapselung von Abhängigkeiten
201
Q

Was sind die Nachteile von Layers-Muster?

A
  • Geringe Effizienz
  • Mehrfache Arbeit (Fehlerkorrektur)
  • Definition richtige Anzahl Schichten
202
Q

Wo wird das Layers-Schichten Muster genutzt?

A
  • APIs
  • Datenbanken
  • Betriebssysteme
  • Kommunikation
203
Q

Wofür eigenen sich Pipes und Filters?

A
  • Eignet sich für Systeme die Datenströme verarbeiten.
  • Arbeitssschritte werden in Filter gekapselt und lassen sich beliebig anordnen oder trennen
204
Q

Was nutzt das Pipes and Filter Muster?

A
  • Kommandointerpreter von Unix
  • Ausgabe ist Eingabe für das nächste Werkzeug
205
Q

Was tut ein Filter?

A
  • Holt Eingabedaten
  • Wendet Funktionen darauf an
  • Liefert Ausgabedaten
  • Zwei aktive Filter sind durch eine Pipe verbunden, beide Filter arbeiten parallel
206
Q

Wie kann ein Filter mit Daten interagieren?

A
  • Daten anreichern
  • Daten verfeinern
  • Daten verändern
207
Q

Wie kann ein Filter aktiv werden?

A
  • Pipeline holt Daten aus Filter
  • Pipeline schickt Daten an Filter
  • Meisten Filter selber aktiv durch Daten holen oder schicken
208
Q

Was macht eine Pipe?

A
  • Eine Pipe verbindet Filter miteinander
  • Verbindet Datenquelle mit ersten und letzten Filter und der Datensenke
209
Q

Wofür ist eine Pipe zuständig?

A
  • Übermittelt Daten
  • Puffert Daten
  • Synchronisiert aktive Nachbarn
210
Q

Wofür sind Datensenken und Datenquellen zuständig?

A
  • Sind die Endstücke der Pipeline und Verbindung zur Außenwelt
  • Übermittelt Daten aus oder an Pipeline
211
Q

Was ist eine aktive und passive Datenquelle?

A
  • aktiv: Reicht Daten ein
  • passiv: wartet bis nächster Filter anfordert
212
Q

Was ist der Vorteil von Pipes and Filters?

A
  • Flexibilität durch Austausch/Entfernen von Filtern
  • Flexibilität durch Neuanordnung
  • Zwischendateien nicht nötig, aber möglich
  • Parallel Verarbeitung möglich
213
Q

Was ist der Nachteil von Pipes and Filters?

A
  • Die Kosten von Übertragung sind hoch
  • Überflüssige Konvertierungen zwischen Filtern
  • Fehlerbehandlung schwierig
  • Effizienzsteigerung durch Parallelisierung schwierig
214
Q

Wann wird das Blackboard Muster angewandt?

A
  • Bei Problemen ohne eindeutige Lösungsidee
  • z.B. Spracherkennung, Bildverarbeitung, Überwachungssysteme
215
Q

Wie funktioniert ein Blackboard?

A
  • Blackboard ist zentrale Datenstruktur
  • Agenten verarbeiten und generieren Wissen
  • Steuerung entscheidet welcher Agent neues Wissen korrekt erfasst hat und aktiviert nächsten Agenten
216
Q

Wie geschehen Zugriffe von Agenten auf das schwarze Brett?

A
  • Zugriff via Konnektoren
  • Konnektoren sind entkoppelt und austauschbar
  • Parallele Auführung von Agenten möglich
217
Q

Was sind Eigenschaften eines Blackboard Systems?

A
  • Das Verhalten ist nicht deterministisch und schwer prüfbar
  • Bei Bild, Ton, Sprache, Schrift wird oft nach nichtdeterministischen Lösungen gesucht
218
Q

Was ist das Domain-Driven Design?

A
  • Domain Driven Design ist eine Denkrichtung zur Steigerung von Produktivität bei komplexenen fachlichen Anforderungen
219
Q

Auf welchen Annahmen basiert Domain Driven Design?

A
  • Softwaredesign liegt an Fachlichkeit und Fachlogik
  • Entwurf komplexer Zusammenhänge sollte auf Domänenmodell basieren
220
Q

Ist der Domain Driven Prozess an einen Entwicklungsprozess gebunden?

A
  • Nicht direkt, aber an agiler Softwareentwicklung angelehnt
  • Setzt iteratives vorgehen und Zusammenarbeit zwischen Entwickler und Fachbereich voraus
221
Q

Was ist ein Konzept des Domain Driven Designs?

A
  • Das Einführen einer einheitlichen Sprache, welche die Fachlichkeit der Klassen und Methoden definiert
    *
222
Q

In was unterscheidet das Domain Driven Design?

A
  • Entitäten (Objekt durch Identität definiert “Person”)
  • Wertobjekt (Objekt durch Wert definiert, oft unveränderlich und verteilbar “Konfiguration”)
  • Aggregation (Zusammenfassung von Entitäten “Datenbanktransaktion”)
  • Assoziation (Beziehungen zwischen zwei oder mehr Objekten)
  • Serviceobjekte (Zustandslose Klassen “API Wrapper”)
  • Fachliche Ereignisse (Objekte mit komplexen dynamischen Änderungen)
    Module (teilen in fachliche Bestandteile)
  • Fabriken (Fachobjekhersteller)
  • Repositories (Suche nach Fachobjekten und Zugriff von Fachlogik getrennt, stellt Objekte bereit.
223
Q

Was bedeutet Evolvierende Struktur im Domain Driven Design?

A
  • Große Strukturen sollten sich erst über die Zeit entwickeln
  • Große Strukturen möglichst einfach umsetzen
224
Q

Was ist die Systemmetapther im Domain Driven Design?

A
  • Die Systemmetapher gehört zum Extreme Programming
  • System wird mittels für jeden verständliche Alltagsgeschichte erklärt
225
Q

Wie sind die Verantworlichkeitsschichten im Domain Driven Design?

A
  • Entscheidungsschicht
  • Regelschicht
  • Zusagen
  • Arbeitsabläufe
  • Potential
226
Q

Was sind Erweiterungsframeworks im Domain Driven Design?

A
  • verschiedene Systeme über Komponenten Framework verbinden
227
Q

Wie geht Domain Driven Design vor?

A
  • Gibt Regel der Vorgehensweise vor
  • Ist gut wenn mehrere Teams in verschiedenen Management und Fachlichkeiten im selben Projekt arbeiten
228
Q

Was ist die Kontextübersicht im Domain Driven Design?

A
  • Gemeinsame Übersicht aller Modelle, Grenzen, Schnittstellen
  • Kontexte bleiben seperat und verwachsen nicht ineinander
229
Q

Was sind die Kontextgrenzen im Domain Driven Design?

A
  • Definieren die Grenzen eines Kontexts in Teamzuordnung, Datenbankschema, Verwendung
230
Q

Was beschreibt die Kernfachlichkeit im Domain Driven Design?

A
  • Meist genutzer Teil des Domänenmodells
  • Kernfachlichkeit hat höchste Priorität und sollte wichtigsten Entwickler erhalten
231
Q

Was ist ein geteilter Kern im Domain Driven Design?

A
  • Ein Teil der Fachlichkeit der zwischen Projektteilen geteilt wird
  • Geteilter Kern wird durch unterschiedliche Teams gemeinsam entwickelt
232
Q

Was ist “Kunde Lieferant” im Domain Driven Design?

A
  • Beziehung im Projekt bei denen ein Team die Fachlichkeit umsetzt
    und das andere Team darauf aufbaut.
233
Q

Was ist ein separierter Kern im Domain Driven Design?

A
  • Kern auch bei enger Kopplung in ein eigenständiges Modul zu legen
  • Kern soll vor Komplexität und Unwartbarkeit geschützt werden
234
Q

Was sind generisiche Sub Fachlichkeiten im Domain Driven Design?

A
  • Teile des Domänenmoduls die nicht Kernfachlichkeit sind in generische Modellen in eigene Module zu legen
  • Können outgesourced entwickelt oder durch gekaufte Software ersetzt werden
235
Q

Was ist Continious Integration im Domain Driven Design?

A
  • Alle Veränderungen im Domänenmodell werden laufend miteinander integriert und automatisiert getestet
236
Q

Was ist die Quintessenz von Domain Driven Design?

A
  • Sehr komplexe Domänenlogik kann einfach modelliert werden
  • Systeme werden besser entkoppelt und wartbar
237
Q

Was ist Serviceorienterte Architektur(SOA)?

A
  • Ein Paradigma für Strukturierung und Nutzung verteilter Funktionalität von unterschiedlichen Benutzern verantwortet
  • SOA orientiert sich an Geschäftsprozessen
  • Geschäftsprozesse sind Grundlage für Serviceimpementierung
  • Applications werden hinter standardisierten Schnittstellen verborgen
238
Q

Was ist das Ziel von Serviceortientierten Architektur? (SOA)

A
  • SOA soll IT Systeme strukturiert und zugänglich machen
  • SOA
239
Q

Was ist ein Beispiel für Geschäftsprozesse in Serviceorientierte Architektur (SOA)?

A
  • “Vergib einen Kredit”
  • “Eröffne Konto”
  • “Kreditvertrag”
240
Q

Wie können in der Serviceorientierten Architektur (SOA) abstraktere Services erstellt werden?

A
  • Durch Zusammensetzen aus niedrigen Services können flexibel komplexere Service geschaffen werden
  • IT Systeme sollten komplexe Dienste anbieten nicht einzelne Berechnungen oder Abfragen.
241
Q

Wie werden Serviceorientierte Architekturen oft angeboten und wie kommunizieren sie?

A
  • In der Coud oder im Internet
  • Kommunikation über REST, XML
242
Q

Was ist einem Nutzer einer Serviceorientierten Architektur (SOA) über das System bekannt?

A
  • Welche Dienste es gibt
  • Welche Eingaben und Ergebnisse er bekommt
  • Er weiß nicht wie das Ergebnis berechnet wurde
243
Q

Was ist ein Dienst in einer Serviceorientierten Architektur (SOA)?

A
  • Dienst repräsentiert eine fachliche Funktionalität
  • Dienst ist abgeschlossen und eigenständig
  • Dienst ist im Netzwerk verfügbar
  • Dienst hat wohldefinierte öffentliche Schnittstelle
  • Dienst ist plattformunabhängig und erreichbar über verschiedene Plattformen/Sprachen
244
Q

Was sind die Vorteile Serviceorientierter Architektur(SOA)?

A
  • Agiles System kann sich schnell verändern
  • Kosten gering durch Wiederverwendung
  • Hohe Leistung, Skalierbarkeit
  • Kann schnell gebaut werden
245
Q

Was sind die NachteileServiceorientierter Architektur(SOA)?

A
  • Oftmals überschätzt, da im Trend
  • Höherer Aufwand als alte Systeme
  • SOA Code ist komplexer
  • SOA Entwickler müssen sehr hohes Wissen haben
  • Unternehmer wird an Entwickler gebunden
246
Q

Was ist ein Peer To Peer Netzwerk?

A
  • Alle Computer sind gleichberechtigt, können Dienst bereitstellen oder nutzen
    *
247
Q

Wie funktioniert ein Peer To Peer Netzwerk?

A
  • Teilnehmer werden in Gruppen eingeteilt nach Qualifikation
  • Beste Computer des Netzwerkes bilden ein Overlay-Netz und stellen Suchfunktionen bereit
248
Q

Was ist ein strukturiertes Peer To Peer Netzwerk?
Was ist ein unstrukturiertes Peer To Peer Netzwerk?

A
  • strukturiert:
    Verantwortlichkeit für jedes Objekt ist mindestens einem Peer zugeteilt
  • unstrukturiert:
    Objekte haben keine Zuordnung im Netzwerk
249
Q

Wie werden Daten im Peer To Peer Netzwerk übertragen?

A
  • Wenn Objekt durch Peer gefunden und gespeichert wird die Datei von Peer To Peer übertragen
  • Verteilungsstrategien können z.B. über BitTorrent sein
250
Q

Was sind Eigenschaften eines Peer To Peer Netzwerkes?

A
  • Gleichberechtigung in Bandbreite, Rechenkraft, Uptime
  • Verfügbarkeit und Qualität von Peers ist keine Voraussetzung
  • Peer bieten Dienste an und nehmen sie in Anspruch
  • Peer haben Autonomie
  • P2P ist selbtorganisierend
251
Q

Was sind die Vorteile eines Peer To Peer Netzwerkes?

A
  • Alle Computer sind gleichberechtigt
  • Kostengünstig, da keine Server
  • Kein zentraler Server notwendig
  • Benutzer verwalten sich selbst
  • Keine Hierarchie
252
Q

Was sind die Nachteile eines Peer To Peer Netzwerkes?

A
  • Schwer zu administrieren
  • Auf kein Peer ist Verlass
253
Q

Was tut das Client Server Modell?

A
  • Verteilt Aufgaben und Dienstleistungen im Netzwerk
254
Q

Was tun Client, Server und Dienste im Client Server Modell?

A
  • Client kann Dienst von Server anfragen
    • Server beantwortet Anfragen
  • Server bietet Dienst an
  • Server kann für mehrere Clients arbeiten
255
Q

Was sind Eigenschaften im Client Server Modell?

A
  • Kommunikation zwischen Client und Server abhängig von Dienst
  • Dienst bestimmt welche Daten ausgetauscht werden
  • Server ist passiv und wartet
  • Clients und Server können auf gleichen oder verschiedenen Rechner laufen
  • Server kann zu einer Gruppe von Servern werden
256
Q

Was sind die Vorteile des Client Server Muster?

A
  • Hohe Skalierbarkeit
  • Einheitliches Finden von Objekten
257
Q

Was sind die Nachteile des Client Server Muster?

A
  • Server muss immer erreichbar sein
  • Server muss Datenverlust gesichert sein
258
Q

Was sind Architekturmuster

der Kategorie

Interaktive Systeme?

A
  • Model View Controller (MVC)
  • Model View Presenter
  • Presentation Abstraction Control (PAC)
259
Q

Was ist das Model View Controller Muster (MVC) und woraus besteht es?

A
  • Ist eine spezielle Version des Layer Muster
  • Besteht aus:
  • *Model** (Datenspeicherung und Zugriff)
  • *Controller** (Programmlogik)
  • *View** (Darstellung für Benutzer)
260
Q

Wie sieht ein Ablauf eines Model View Controller Musters aus?

A
261
Q

Warum benutzt man das Model View Controler Muster (MVC)?

A
  • APIs müssen oft geändert werden
  • Daten sollen unterschiedlich dargestellt werden
  • Verschiedene APIs anbieten ohne Kern zu ändern
262
Q

Was tut das Model im Model View Controler Muster?

A
  • Kapselt Daten und Funktionalität
  • Ist unabhängig von Darstellungen oder Eingaben
  • Model enthält die Kernfunktionalitäten der Anwendung
263
Q

Was tut das View im Model View Controler Muster?

A
  • Sicht zeigt Benutzer Infos an
  • Es kann mehrere Sichten geben
264
Q

Was tut der Controller im Model View Controller Muster?

A
  • Controller verarbeitet Eingaben und ruft Dienste auf
  • Controller ist Sicht zugeordnet
  • Es kann mehrere Controller geben
265
Q

Was ist der Vorteil des Model View Controller Muster?

A
  • Mehrere Views für ein Modell
  • Synchronisation von Views
  • Austauschbarkeit von Views und Controller
  • Gut für Frameworks
266
Q

Was ist der Nachteil des Model View Controller Muster?

A
  • Hohe Komplexität
  • Oft aktualisieren
  • Ineffizienter Zugriff auf Datenmodell
  • Starke Kopplungen Model - View und Model - Controller
267
Q

Was ist das Model View Presenter Muster?

A
  • Hervorgegangen aus MVC, jedoch Model und View über Presenter getrennt
  • Komponenten streng getrennt
268
Q

Wie sieht ein Model View Presenter (MVP) Muster aus?

A
269
Q

Wie macht das Model im Model View Presenter (MVP) Muster?

A
  • Stellt Logik für Ansicht dar
  • Model muss alle Funktionalitäten anbieten
  • Steuerung vom Model nur durch Presenter
  • Model kennt keine View und kein Presenter
270
Q

Wie macht die View im Model View Presenter (MVP) Muster?

A
  • Enthält keine Logik
  • Nur Darstellung für Ein und Ausgaben
  • Kein Zugriff auf Presenter oder Model
  • Ganze Steuerung geschieht durch Presenter
271
Q

Wie macht der Presenter im Model View Presenter (MVP) Muster?

A
  • Verbindet und steuer Model und View
  • Bringt View zum funktionieren
272
Q

Was sind Bedingungen im Model View Presenter (MVP) Muster?

A
  • Model und View eigene Schnittstellen
  • Schnittstellen definieren den exakten Aufbau der Schichten
  • Presenter verknüpft die Schnittstellen
273
Q

Was ist der Vorteil des Model View Presenter (MVP) Muster?

A
  • Mehrere Sichten des gleichen Modells
  • Synchronisation aller Views
  • Austausch und Wiederverwendbar
  • Gute Testbarkeit der Views
274
Q

Was ist der Nachteil des Model View Presenter (MVP) Muster?

A
  • Hohe Komplexität
  • Oft Aktualisieren
  • Ineffizienter Datenzugriff auf Modell
  • Komplex umsetzbar
275
Q

Was ist das Presentation Abstraction Control Muster (PAC)?

A
  • System ist aus vielen eigenständigen Einzelsystem zusammengesetzt für hohe Flexibilität
  • Einteilung in Presentation, Abstraction, Control
  • Hierarisch in Agenten die Teile erledigen aufgeteilt
  • Für größere Systeme
276
Q

Was tun Agenten im Presentation Abstraction Control (PAC) Muster?

A
  • Stellen erste Stufe für Strukturierung der Architektur dar
  • Alle Anforderungen werden auf Agenten zugeteilt
  • Hierarische Struktur
  • Jeder Agent wird in Presentation, Abstraction und Control aufgeteilt
277
Q

Wie sind die Hiearchien der Agenten im Presentation Abstraction Control (PAC)?

A
  • Top Level Agent (Nur einer!):
    Globale Aufgaben wie Datenbankzugriff
  • Intermediate Level Agent:
    Strukturiert die Bottom Level Agenten in Teilsysteme
  • Bottom Level Agent:
    abgeschlossene Aufgaben
278
Q

Wie sind Agenten im Presentation Abstraction Control (PAC) Muster aufgeteilt?

A
  • Jeder Agent ist in drei Komponenten strukturiert
  • Dabei muss er nur Datenmodell und Benutzerschnittstelle liefern, den Rest kann er implementieren
  • Presentation für Benutzeroberfläche, Ein und Ausgabe
  • Abstraction für Datenmodell
  • Control für Verbindung der Komponenten und Kommunikation mit anderen Agenten
279
Q

Wie sind die Vorteile des Presentation Abstraction Control (PAC) Muster?

A
  • Zerlegung des Systems in semantische getrennte Teile
  • Erweiterbarkeit durch neue Agenten
  • Wartbarkeit gut durch interne Struktur der Agenten
280
Q

Wie sind die Nachteile des Presentation Abstraction Control (PAC) Muster?

A
  • Hohe Komplexität von System und Steuerung
  • Hohe Koordination/Kommunikation der Agenten
281
Q

Was sind Muster

der Kategorie

Adaptive Systeme?

A
  • Mikrokernel
  • Reflexion
  • Dependency Injection
282
Q

Was ist ein Mikrokernel Muster?

A
  • Mikrokernel bietet Basis für Erweiterungen und sorgt für Zusammenarbeit
  • Dynamische Änderung von Systemanforderungen zur Laufzeit
283
Q

Was sind Beispiele für Mikrokernel?

A
  • SymbianOS
  • Minix Kernel
284
Q

Was sind Beispiele für Monolithische Kernel?

A
  • Linux
  • Android
  • Windows
285
Q

Was sind Beispiele für Hybridkernel?

A
  • MacOS
286
Q

Was sind die Vorteile des Microkernels?

A
  • Austauschbarkeit der Komponenten
  • Sicherheit, da Treiber im Benutzermodus
  • Skalierbarkeit
  • Zuverlässigkeit
  • Transparenz
287
Q

Was sind die Nachteile für Mikrokernel?

A
  • Leistung
  • Komplexität
288
Q

Wie wähle ich das richtige Architekturmuster aus?

A

xxxx

289
Q

Wie können Architekturen dokumentiert werden?

A
  • Durch die Nutzung von Templates wie:
    Arc42
    Normen
    Software Guidebook
290
Q

Was ist arc42?

A
  • Ein Template für Dokumentationen aus der Praxis und Erfahrung vieler Architekten
  • Besteht aus definierten Inhaltsverzeichnis, welches man abarbeitet
291
Q

Was ist Inhalt des Inhaltsverzeichnis von arc42?

A
  1. Einführung und Ziele:
    Aufgabe, Qualität, Stakeholder
  2. Randbedingungen:
    Technische, Organisatorische, Konventionelle Einschränkungen
  3. Kontextabgrenzung:
    Fachlich, Technisch
  4. Lösungsstrategie:
    Wie funktioniert die Lösung?
  5. Bausteinsicht:
    Struktur des Systems
  6. Laufzeitsicht:
    Wie funktionieren Bausteine zur Laufzeit zusammen?
  7. Verteilungssicht:
    Welche Hardware betreibt die Bausteine?
  8. Querschnitt Konzept und Muster:
    Muster, Strukturen, Konuepte, Nutzung und Anleitung für Technologien
  9. Entwurfsentscheidungen
  10. Qualitätsszenarien:
    Konkrete Szenarien von Qualität
  11. Risiken:
    Liste Priorisierter Risiken
  12. Glossar:
    Wichtigste Begriffe
292
Q

Was sind die IEEE Standards?

A
  • Sind von einem Amerikanischen Komittee entwickelt worden
  • Definieren und Spezifizieren LAN, WLAN etc
  • IEEE 830-1998 spezifiert Software mit Lasten und Pflichtenheft
293
Q

Was ist das Software Guidebook zur Software Dokumentation?

A
  • Ein Template von Simon Brown
  • Es geht darum um praktische Informationen:
    Karten
    Sichten
    Geschichte
    Praktische Informationen!
294
Q

Was ist der Inhalt des Software Guidebooks?

(Nicht wichtig!)

A
  1. Context:
    Was bauen wir, warum, wie passt es in systeme, wer benutzt es?
  2. Functional Overview:
    Hauptfunktionen
    Was tut es, welche use cases sind wichtig?, Informationsflüsse?
  3. Quality Attributes:
    Qualitätsattribute (Performanz, Skalierbarkeit, Verfügbarkeit, Sicherheit, Erweiterbarkeit, Flexibilität, Wartbarkeit ..)?
    Klares Verständnis? Sind die Attribute Messbar, spezifisch, erreichbar, relevant, umsetzbar? was ist unrealistisch?
  4. Constraints:
    Es gibt im echten Leben immer Einschränkungen. (Zeit, Budget, Technologien, Standards, Protokolle, Größe des Teams, Erfahrung, Politisch, Lizenzen)
  5. Principles:
    Schichten-Strategie, Keine Logik in GUI, Kein Datenbankzugriff in GUI, Dependency Injection, Hohe Kohäsion, geringe Kopplung
  6. Software Architecture:
  7. External Interfaces:
  8. Code
  9. Data
  10. Infrastructure Architecture
  11. Deployment
  12. Operation and Support
  13. Development Environment
295
Q

Was ist das Framework NodeJS?

A
  • Serverseitige Plattform für Netzwerk Anwendungen
  • Seit 2009 Google Chrome JavaScript Engine
  • Soll schnell, verlässlich und skalierbar sein
  • Evenbezogen, Input Output ohne Blockaden
  • Gut für echtzeitdaten
  • Große Library
  • Node.JS = Runtime Environment + Javascript Library
  • Genutzt von Ebay, Microsoft, Paypsal etc
296
Q

Was sind Feature von NodeJS?

A
  • Asynchron und Even Driven
  • Sehr schnell
  • Single Threaded aber hoch skalierbar
  • Kein Buffering
  • MIT License
297
Q

Wann sollte man NodeJS benutzen?

A
  • IO gebundene Applikationen
  • Data Streams
  • Echtzeit Programme
  • JSON APIs
  • Single Pager
298
Q

Was sind die Grenzen von NodeJS?

A
  • CPU intensive Applikationen
299
Q

Was ist Angular JS?

A
  • Clientseitiges JavaScript Webframework für Single Page Websites nach dem Model View View Model Muster
  • Benutzt jQuery
  • Validierung von Eingabeformularen möglich
300
Q

Was sind die Vorteile von AngularJS?

A
  • Testbarkeit
  • Refaktorisierung
  • Wiederverwendbarkeit
  • Javascript Datentypen
301
Q

Was sind die Nachteile von AngularJS?

A
  • Nur Clientside
  • Performance
  • Sehr komplex
302
Q

Was ist Advanced Message Queuing Procol (AMQP)?

A
  • AMQP ist ein quelloffenes Netzwerkprotokoll für Message orientierte Middleware
  • AMQP ist programmiersprachen unabhängig und JMS kompatibel
303
Q

Was ermöglicht AMQP?

A
  • Messaging bringt Skalierung
  • Anwendungen verbinden sich wie Komponenten eines größeren Systems
  • Messaging is asynchron
304
Q

Wann sollte man AMQP benutzen?

A
  • Datenübertragung
  • Push Benachrichtigung
  • Asynchrone Datenverarbeitung
305
Q

Was ist Twitter Bootstrap?

A
  • Freies HTML/CSS Framework
  • Für Schriften, Forumulare, Buttons, Tabellen etc.
  • Verwendet HTML5
  • Mobile first Grundgedanke
  • Browserunabhängigkeit
  • Arbeitet mit Containern im Grid System
306
Q

KLAUSUR:
Wie entsteht Architektur?

A
  • Architektur entsteht in Zyklen durch iteratives Vorgehen
307
Q

KLAUSUR:
Was bedeutet Softwarekrise?

A
  • Der Punkt, an dem Software teurer als Hardware wurde
  • Rechner kosteten Millionen und Software wenig, dann ist es gekippt
308
Q

KLAUSUR
Was lief an Projekten wie IBM OS/360 schief?

A
  • Wegen der Softwarekrise wurde es extrem verschätzt.
  • Das Projekt zog sich immer weiter, wurde immer teurer und keine Einnahmen enstanden, da es nicht fertig wurde
309
Q

KLAUSUR
Welche Arbeitsmodelle wuren zuerst entwickelt und warum abgelöst?

A

Das Wasserfall und VModell wurde zuerst entwickelt, aber dann als die Software zu komplex dafür wurde durch agile Methoden abgelöst.

310
Q
A
311
Q
A
312
Q
A
313
Q
A
314
Q
A
315
Q
A