TU Wien:Software Architecture VU (Dorn)

Aus VoWi
Wechseln zu: Navigation, Suche

Daten[Bearbeiten]

Inhalt[Bearbeiten]

  • Verschiedene Arten und Stile der Software-Architektur
  • Konnektoren
  • Architekturmodellierung in Architekturbeschreibungssprachen
  • Implementierungskonzepte

Nicht behandelt werden praktische Umsetzungskonzepte. Software Architekture wird auf einer eher abstrakten Ebene erklärt.

Ablauf[Bearbeiten]

  • Geblockter Frontalvortrag (5 VO Einheiten)
  • Ein in Gruppen (3-5) zu lösendes Übungsbeispiel mit zwei Abgaben (einmal Modellierung und Konzept, einmal Implementation und Modelladaption)
  • Präsentation der ersten Übungsaufgabe
  • Gemeinsames Abgabegespräch
  • Schriftliche Prüfung

Benötigte/Empfehlenswerte Vorkenntnisse[Bearbeiten]

  • Programmierkentnisse von Vorteil, da in der Übung 1 die Architektur einer OpenSource-Applikation analysiert werden muss.
    (Bei den Applikationen sind u.a. folgende Programmiersprachen vertreten: Java, C, C++, Python, "HTML"/JavaScript, Perl...)

Vortrag[Bearbeiten]

Der Vortragsstil war für mich etwas trocken, dass lag evtl. auch an den eher abstrakten Inhalten. Der praktische Bezug wird mMn leider nur dürftig aufgezeigt und ist nicht immer sofort ersichtlich. Der Vortragende versucht aber mit vereinzelten Fragen etwas Abwechslung in die VOs zu bringen. Achtung: lasst euch nicht von den einfachen "Zwischenfragen" in der VO über die Prüfung hinwegtäuschen.

Übungen[Bearbeiten]

Im WS13 war eine verteilts "music identification service" system zu bauen (SWAzam) das aus Client, Server und Peer-Network besteht.

  • Die erste Abgabe enthält die Architekturbeschreibung für jede Komponente in xADL und ein ergänzendes Modell in bspw. UML
  • Die zweite Angabe ist die eigentliche Implementation, ein möglicherweise adaptiertes Modell und eine relativ umfangreiche Beschreibung

Im WS14 gab es zwei Übungen, beide in einem Team von 4-5 Studierende, zu lösen:

  • Assignment 1: Aus einer Liste von OpenSource-Anwendungen muss eine Anwendung genauer beschrieben und präsentiert werden. (Verschiedene Diagramme erstellen, 2 Qualities und Tactics auswählen und beschreiben)
  • Assignment 2: Entwicklung von "SWAzam", ein "distributed music recognition system". "Entwicklung" bedeutet hierbei aber das Erstellen einer Software Architektur. (Peer-to-Peer + weitere Anforderungen wie 99.99% Verfügbarkeit, usw.) Es muss nichts programmiert werden.

Für beide Übungen mussten u.a. Design-Modelle erstellt werden. Hierzu kann ein beliebiges Modellierungstool verwendet werden (VisualParadigm, Papyrus, TOPCASED, PlantUML,... bzw. xADL auf eigene Gefahr). "General Purpose"-Tools wie Dia, Visio, Powerpoint durften nicht eingesetzt werden.

Prüfung, Benotung[Bearbeiten]

Schriftliche closed-book Prüfung, 5 Fragen, 60 Minuten Zeit. Die Prüfung ist optional und trägt nur zu 30% der Gesamtnote bei. Es gibt nur zwei Prüfungstermine.

Er zieht schon ordentlich Punkte ab bei den Übungen, es is nur nicht wirklich ganz klar wofür eigentlich

WS2014:

  • Schriftliche Prüfung (closed-book) mit 3 Fragen und 45 Minuten Zeit. Bei den Fragen sind jeweils 10 Punkte zu erreichen.
    Achtung: der Fokus der Vorlesung und der Prüfung sind nicht unbedingt gleich. Für die 1. Prüfung im WS2014 ist es (IMHO) nicht ausreichend nur aus den Folien zu lernen, bzw. sollte man jede Folie sehr gut verstanden haben. In der Prüfung wurden z.T. sehr spezifische Fragen gestellt.
  • Die Gesamtnote setzt sich aus der Prüfung (30 Punkte), dem Assignment 1 (40 Punkte) und dem Assignment 2 (30 Punkte) zusammen. In Summe müssen mindestens 50 Punkte erreicht werden.

Dauer der Zeugnisausstellung[Bearbeiten]

  • Prüfung 25.11.2014: E-Mail bzgl. Note am 28.11.2014.
  • Finale Deadline: 26.01.2015. Zeugnisausstellung am 02.03.2015

Zeitaufwand[Bearbeiten]

Die Übungsaufgabe ist ziemlich Umfangreich wenn man ein halbwegs gut funktionierendes System bauen will

Unterlagen[Bearbeiten]

Tipps[Bearbeiten]

  • Baldrian schlucken wenn ihr ArchStudio öffnet
  • Viele Komponenten und Konnektoren zeichnen, dabei eher Abstrakt denken als zu sehr an die implementation
  • Das Konsistenzargument für die zweite Abgabe ist ihm sehr wichtig. Er meint zwar, Myx muss nicht verwendet werden, aber textuelle Konsistenzbeschreibungen führen garantiert zur Punkteabzügen
  • Wichtig ist ihm außerdem, dass das Peer-to-peer Netzwerk skalierbar designed ist

Verbesserungsvorschläge / Kritik[Bearbeiten]

  • Es ist nicht so ganz klar wo der Fokus bei der Übung liegen soll, einerseits meint er, implementation sei ihm nicht so wichtig, andererseits will er ein skalierbares Peer-To-Peer netzwerk haben
  • Der Vortrag ist eher meh. Man hat nicht wirklich das gefühl, dass er tiefes Verständnis vom Stoff hat
  • ArchStudio und xADL sind wirklich Schrott...
  • Bitte etwas mehr Praxisbezug. Bei den ganzen Styles, Pattern, DSSAs,... weiß man schnell nicht mehr auf welcher "Ebene" in der SW-Entwicklung man sich befindet. Das Luna-Lander-Beispiel fand ich dazu nicht sehr passend.
  • Die Foliensätze 1-3 (Basic Concepts, Connectors, Quality Attributes+Tactics) fand ich sehr chaotisch und unstrukturiert.