Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Praktische Softwaretechnik (SWE Modell B) » softwarearchitektur_ss20   (Übersicht)

Fach: Softwarearchitektur

Prüfer: Dr. Martin Jung

Beisitzer: Name nicht bekannt

Note: 1.0

Zusammenfassung:

Durchaus eine lockere Stimmung trotz der Corona-Maßnahmen. Der Prüfer war sehr freundlich und hat von sich aus auch versucht weiterzuhelfen, als ich mal auf dem Schlauch stand.

Wie vorher eingeschätzt legte Herr Jung weniger Priorität auf das Auswendiglernen und Runterrattern von Definitionen oder Begrifflichkeiten, sondern dass man Zusammenhänge verstanden hat und diese in eigenen Worten darstellen kann.

Bei der Vorbereitung hat mir sehr geholfen, dass ich mir eigene Fragen und passende Antworten dazu ausgedacht habe und eigene Beispiele überlegt habe (nicht zu sehr auf die Beispiele im Skript vertiefen sondern die Themen in einen eigenen Kontext stellen). Dadurch tat ich mir leichter, die Sachverhalte zu erklären.

Zusammenfassend eine sehr angenehme Prüfung, es wurden keine gemeinen Fragen gestellt und die 30m gingen doch schneller um als gedacht.

Die Fragen spiegeln sinngemäß den Verlauf der Prüfung wider.

Wie würden Sie jemanden den Begriff Softwarearchitektur beschreiben?

Standardfrage zu Beginn. Ich habe hier keine der Definitionen aus dem Skript heruntergebetet, sondern selbst kurz zusammengefasst und beschrieben, was Teile und Aufgaben der SWA sind.

  • statische Architektur (Dekomponierung), wie die Komponenten in Beziehung zueinander stehen, welche Verantwortlichkeiten und Abhängigkeiten die Komponenten besitzen
  • dynamische Beschreibung des Verhaltens der SW
  • Entscheidungen + Begründungen
  • usw.

Aufgabe eines Architekten ist die Erstellung eines Plans, wie ein SW-Teil realisiert werden soll. Auf welcher Basis wird das normalerweise durchgeführt?

Abhängig vom Projekt-Typ. Bei Kundenprojekten existieren die Anforderungen bereits, bei Produktentwicklung müssen diese erst selber erhoben werden.

Wie kommt man von Anforderungen auf die (initiale) Dekomponierung?

Hier habe ich Anforderungsanalyse erklärt, welche Art von Requirements? (funkt./quality) es gibt und was sie ausmacht, die Analyse von UseCases bzw. Szenarien. Basierend darauf existieren Verfahren zur Komponentenfindung → CRC Verfahren kurz erklärt. Welche Schritte existieren und welche Ergebnisse man anschließend erhält.

Welche Eigenschaften sollte eine gute Komponente besitzen?

Kurz Kohäsion und Kopplung in eigenen Worten erklären. Beispiele helfen hier sehr. Anzustreben sind eine schwache Kopplung und starke Kohäsion.

Nach der Durchführung von CRC existieren nun Komponenten-Kandidaten. Welche Möglichkeiten existieren, um gutes Architekturwissen wiederzuverwenden?

Tactics, Styles, Pattern. Jeweils kurz erklärt + Beispiele genannt (Tactic: Errorhandling für Verfügbarkeit, Style: Schichtenarchitektur, Pattern: MVC). Zur Schichtenarchitektur sollte ich noch jeweils Vor- und Nachteile aufführen. Auch hier bietet es sich für die Erklärung an ein Beispiel parat zu haben (z.B. TCP/IP-Stack für die Schichtenarchitektur).

Welche Art von Requirements sind für einen Architekten eher interessanter? Angenommen ein Manager verlangt, dass eine der Funktionen hochverfügbar sein muss und ein anderer Manager verlangt, mehr Performanz. Wie gehen Sie damit um?

Kurz nochmal den Unterschied zwischen funkt. und qualit. Requirements angerissen. Stichwort Prototypen und Spikes: Evaluation möglicher Lösungen. Spikes habe ich kurz mit einem Beispiel erklärt, Prototypen brauchte ich anschließend nicht mehr erklären.

Wie können Sie anschließend entscheiden, welche Lösung Sie umsetzen? Wie können sie die einzelnen Anforderungen priorisieren?

Hier stand ich ein bisschen auf dem Schlauch. Herr Jung wollte auf den Utility-Tree hinaus, um die einzelnen Qualitätsaspekte zu vergleichen und priorisieren können. Er hat mich allerdings mit kleinen Hinweisen doch noch auf die richtige Spur gebracht.

Anschließend sollte ich einen UtilityTree (einen Ast) anhand einens Beispiels aufzeichnen (Whiteboard). Dabei habe ich die einzelnen Ebenen und deren Bedeutung erklärt. Danach sollte ich einen zweiten Ast/ein zweites Qualitätsattribute einzeichnen und in diesem Zusammenhang TradeOff- und Sensitivity-Points erklären.

Können Sie bitte eine Beispiel-Sicht der logischen Architektur zeichnen?

Exemplarische Klassendiagramm aufgemalt mit zwei Komponenten, die über ein Interface in Beziehung stehen (usage + realization). Ich sollte kurz erklären, welche Teile des Diagramms im SourceCode wiedergefunden werden (IF als Header Datei in C++). Man sollte allerdings dennoch alle besprochenen Diagrammarten kennen und auch mit einem Beispiel zeigen können.

Man stellt fest, dass sich die SW ganz anders verhält, als spezifiziert. Woran könnte das liegen bzw. wie geht man diesem Phänomen auf den Grund? Wie kann man verhindern, dass die SW anders implementiert wird, als sie modelliert wurde?

Verifikation, Validierung als reaktive Mechanismen und Generation von SourceCode als konstruktiven Mechanismus.

Was kann man denn noch alles aus dem Architekturmodell generieren?

  • UseCases → Dokumentation, API
  • Klassendiagramm → Testspezifikation für Integrationstests

Welche Kontrollverfahren auf Architekturebene und SourceCode-Ebene haben wir kennengelernt? Welche Metriken kennen Sie?

Jeweils ein paar Metriken für beide Ebenen genannt und diese kurz erklärt.

  • SourceCode: LoC, Kommentardichte, Tiefe der Vererbungshierachie, …
  • Architektur: Anzahl an Requirements pro Komponente, Komponenten pro UseCase (wie viele Komponenten gemittelt die Funktionalitäten der UseCases umsetzen)

Was sagt die Metrik „Anzahl an Komponenten pro UseCase“ über die SW aus?

Starrheit der SW, wie gut auf Änderungen (in einem der UseCases) reagiert werden, welche Auswirkungen das hat (zeitlich, finanziell)

Wir haben neben der logischen Sicht noch andere Sichten kennengelernt. Welche denn und wie zeichnen sich diese aus?

Kruchten 4+1, hier habe ich die anderen Sichten beschrieben, welche Diagrammarten existieren, für welche Stakeholder die Sichten gedacht sind.

Was würde sie mit der Zahl anfangen: Die prozentuale Anteil an Komponenten pro Artefakt?

Kommt darauf an, wie oft meine Software verändert wird. Wenn 100% aller Komponenten in einem Artefakt realisiert sind ich aber jede Woche ein neues Update veröffentliche, ist das natürlich unnötiger Mehraufwand (vice versa).

Domain Specific Modeling: Was versteht man unter „Product Line Engineering“ und welche Auswirkungen hat das auf die Softwarearchitektur?

PLE erklärt, mehrere Produkte des gleichen Unternehmens mit unterschiedlichen Feature-Sets und einer gemeinsamen Basis-Funktionalität und Basis-Architektur.