Du befindest dich hier: FSI Informatik » Prüfungsfragen und Altklausuren » Hauptstudiumsprüfungen » Praktische Softwaretechnik (SWE Modell B) » softwarearchitektur_ss18 (Übersicht)
Fach: Softwarearchitektur
Prüfer: Dr. Martin Jung
Beisitzer: Mir leider nicht bekannt
Note: 1.0
Einstieg war alles ganz locker, aber es wurde dann doch relativ direkt durchgestartet. Hier der Ablauf:
Was ist die Definition von Softwarearchitektur?
Eine beliebige Def. runtergerattert, die ich für den Einstieg auswendig gelernt hatte.
Was sind denn diese von Ihnen angesprochenen „Stakeholder“? Geben Sie mir ein Beispiel, für was interessieren die sich?
- Kunde: Zeit, Budget, Funktionalität
- Entwickler: Logische Komponenten, dynamisches Verhalten, interne Szenarien
- Marketing: Funktionialität, …
- Management: geschätzte Zeit, …
Wenn die sich für verschiedene „Aspekte“ interessieren, dann kann man das entsprechend darstellen. Wie macht man das?
Habe die 4+1 Kruchten Sichten genannt, wurde aber unterbrochen…
Bevor Sie jetzt alle durcharbeiten, zeigen Sie das doch bitte anhand von passenden Diagrammen.
Habe dann entsprechende Diagramme gezeichnet.
- Logische Sicht: Komponentendiagramme
- Prozess-Sicht: An sich beliebiges Interaktionsdiagramm, habe ein Sequenzdiagramm gemacht.
- Entwicklungssicht: Ins Komponentendiagramm über «manifests»-Beziehungen die Artefakte eingezeichnet.
- Physische-Sicht: Deployment-Diagramm eingezeichnet und beispielhaft eine «deploy»-Beziehung zwischen eines der Artefakte und einer Laufzeitumgebung hinzugefügt.
Jetzt haben Sie Ihre Architektur entworfen. Der Kunde kommt nun und verlangt, dass der Aufruf der Funktion „X“ (zeigt auf Diagramm) nur eine Mikrosekunde dauert. Was sagen Sie ihm?
Dass das - je nachdem wie komplex die Funktion dann eigentlich ist - nicht möglich ist.
Woran können Sie das für den Kunden fest machen?
Hier würde sich dann ein Spike eignen (Spike erklärt, mit Mocks, Metriken, Lastgeneratoren, …)
Wir hatten auch einen Prozess für Architekturbewertung kennengelernt…
Da können wir ATAM benutzen. Das funktioniert wie folgt… (habe die Hauptschritte kurz umrissen, Details waren nicht notwendig)
Wie sieht denn so ein Qualitätsbaum aus, der bei ATAM aufgestellt wird?
Habe angefangen ein Beispiel zu zeichnen, er hat mich da ein wenig bzgl der zu verwendenden Qualitäten angeleitet.
Sie haben vorhin beim Beschreiben von ATAM „sensible Punkte“ genannt. Was ist damit gemeint?
Hier habe ich zunächst fälschlicherweise das Beispiel vom „Blackboard“ im entsprechenden Architekturstil als Single Point of Failure gebracht.
Das ist zwar richtig, das ist ein kritischer Punkt, aber ATAM findet da eher was anderes. Keine Angst, da kommen Sie drauf, zeichnen Sie mal folgende Details in den Baum ein.
Hat mich angeleitet „Performance“ und „Zuverlässigkeit“ hinzuzufügen. Er hat mich dann auf den Konflikt hingewiesen, dass man nicht beides gleichzeitig optimieren kann und das so ein sensibler Punkt ist, wo man dann mit dem Kunden abwägen muss.
Was haben wir noch bzgl Bewertung kennengelernt?
ATAM ist ja eine qualitative Bewertungsmethode, wir hatten auch noch Metriken für die Seite der quantitativen. - Metriken erklärt - SW und ARCH Metriken genannt und Beispiele genannt
Ganz kurz ein Stichwort, wie man gute, passende Metriken finden kann?
Goal Question Metric
Ok, abschließend: Wir haben jetzt unsere ARCH wunderbar spezifiziert, was kann man damit jetzt noch machen - abgesehen als Verständnisbasis zwischen Stakeholder und Architekt?
Man kann das Modell auch zur direkten Generierung benutzen.
Was generiert man da typischerweise?
Also meistens das Code-Grundgerüst, d.h. die Komponenten und Klassen.
Wunderbar, dann warten Sie bitte doch kurz draußen…
Allgemein war die Stimmung locker, die Fragen waren nicht gemein gestellt und haben auch immer einen logischen Zusammenhang zum vorherigen Gesprächsverlauf gehabt. Deshalb hat sich das im Endeffekt wie ein Fachgespräch und weniger wie eine Prüfung angefühlt. Man hat auch gemerkt, dass Herr Jung nicht die Intention hatte einem etwas reinzuwürgen, besonderst zB bei der oben genannten Geschichte bezüglich der „Sensiblen Punkte“. Da hat er gemeint das erarbeiten wir jetzt gemeinsam. Auch die Benotung war sehr fair.
Vorbereitet habe ich mich im Verlauf über zwei Wochen, wobei ich die erste hauptsächlich zum Sichten des Stoffs und zum Schreiben von Karteikarten mit Fragen verbracht habe. Die zweite Woche bin ich dann zusammen mit meiner Lerngruppe mehrere Male durch den Stapel gegangen. Insgesamt würde ich sagen, dass ich mich zu „tief“ in den Stoff eingearbeitet habe. Eine flachere, dafür breite Vorbereitung der Themen wäre wahrscheinlich ebenfalls ausreichend gewesen. Die in der Vorlesung als Übung deklarierten Videos habe ich nicht alle angesehen und bin damit auch gut gefahren, mir wäre keine Frage bzgl der Videoinhalte aufgefallen.
Was sich auf jeden Fall lohnt ist seine UML-Kenntnisse aufzufrischen. Der grobe Ablauf beim Erstellen der Diagramme erleichtert es allgemein den Ablauf der Softwarearchitekturerstellung im Kopf zu behalten. Ich hatte dahingehend Glück im selben Semester die UML Vorlesung von Prof. Kips besucht zu haben.