StexInfos

Informationen zum Staatsexamen Softwaretechnik

Auf dieser Seite versuchen wir, Ihnen inhaltliche Informationen zum Staatsexamen Softwaretechnik (Informatik) zusammenzustellen. Diese Seite ist dabei als Hilfestellung für Studenten und Aufgabenersteller, zu denen auch Professoren an der Universität Würzburg gehören, gedacht.

Die untenstehenden Informationen stellen dennoch nur die Meinung der Seitenautoren dar. Keinesfalls sollten untenstehende Informationen als offiziell oder verbindlich betrachtet werden! Die Auswahl geeigneter Inhalte ist alleinige Sache der Aufgabenersteller. Diese haben weder alle Kenntnis von diesem Text, noch sind sie in irgendeiner Weise an ihn gebunden. Dennoch hoffen wir, durch diese Seite in gewisser Weise zur Vergleichbarkeit verschiedener Staatsexamensprüfungen beizutragen.

Studierende des Lehramts Gymnasium schreiben die vertieften Prüfungen, andere Lehrämter die üblicherweise etwas einfacheren nicht-vertieften Prüfungen.

Themenmatrix und alte Aufgabenstellungen

In diesem Abschnitt finden Sie alte Aufgabenstellungen und eine Einordnung der Aufgaben zu bestimmten Themenblöcken. Diese werde im nächsten Abschnitt detaillierter beschrieben.

Softwaretechnik (vertieft)

Examen	Thema	Klassen-diagramm	UML-Diagramme	Program-mierung	Testen	Formale Verifikation	Entwurfs-muster	Wissens-fragen	Projekt-ablauf	Petrinetze	Sonstiges
F2012	T1	2b	2a, 3				4		1
	T2	4b	4a, 5c-d	5a-b	1	3			2
H2012	T1	1a	1b				2
	T2	3		1					2
F2013	T1	1					2
	T2	2, 3a		4		3b, 5b		1a, 5a	1b-c
H2013	T1			4	3	1b		1a	2
	T2	1		3		2
F2014	T1	1a	1b				1c
	T2	2	4a-b	1					3
H2014	T1			1, 2	4	3
	T2	2b		5	3	1, 4	2a
F2015	T1	1	2	3a			3b-c
	T2	2				1				3
H2015	T1	2	3		1
	T2			1		3				2
F2016	T1	1a	1b	2c			2a-b
	T2	2			4a			1	3, 4b-f
H2016	T1	2b	2a	2c	3	4		1
	T2	1	4		3			1
F2017	T1	5	3, 4a	4b				1	2
	T2	2	3		1	4
H2017	T1		3		4			1	1
	T2	2a	2b		4		3		1
F2018	T1				3						1, 2
	T2	1a-b	1c-d, 3	2d		4	2a-c
H2018	T1	2a, 3c	1, 3b, 2c	4		5	2b	3a
	T2	3		5	6, 8		4	7, 10	1, 2, 9

Softwaretechnik (nichtvertieft)

Examen	Thema	Klassen-diagramm	UML-Diagramme	Program-mierung	Testen	Formale Verifikation	Entwurfs-muster	Wissens-fragen	Projekt-ablauf	Petrinetze	Sonstiges
F2012	T1	3a	3b-c	3d, 4				2	1
	T2	1		2
H2012	T1
	T2
F2013	T1	1a	1b					2
	T2	2	1b	1a
H2013	T1
	T2
F2014	T1
	T2	2			3	1
H2014	T1	1									2
	T2	3b	3a, 3c-d					1	2
F2015	T1	2		1					3
	T2	3a	3b	3c				1	2
H2015	T1	1	2	4					3
	T2	1			2	3
F2016	T1	2a	3	2b				1
	T2								3	2	1
H2016	T1	3a-b	4	2a, 3c			2b	1
	T2	1	2	3		4
F2017	T1	3	2				4, 6	1	5
	T2	4b	4a	4c	2		3	1
H2017	T1		2a	2b	4			1	3
	T2		2b				3		1		2a
F2018	T1
	T2
H2018	T1	1	3	2b-c		4	2a
	T2			3, 5	6, 7, 8, 9, 10		4		1, 2

Inhalte

In diesem Abschnitt wollen wir Ihnen einen Überblick über typische Aufgaben und Inhalte der einzelnen Aufgaben geben. Als allgemeiner Trend kann beobachtet werden, dass das Staatsexamen in SWT umfangreicher wird und zumeist aus mehr, dafür kürzeren Aufgaben besteht. Insbesondere ist es deshalb schwierig, eine abschließende Aufzählung des Stoffes anzugeben. Untenstehende Auswahl soll einen ersten Überblick verschaffen. Dass ein Aspekt unten nicht aufgeführt ist heißt aber keinesfalls, dass er noch nicht abgeprüft wurde oder künftig nicht abgeprüft wird!

Klassendiagramm

Häufigkeit:	Kanonisch
Inhalte:	Klassen: Name (Schreibweise): BigCamelCase Typen: normal, Attribute: Sichtbarkeiten: -private, +public, #protected, static Datentypen: An übliche Programmiersprachen angelehnt (z.B. int, Integer, char, Double, bool, Boolean, String, ...). Funktionen: Sichtbarkeiten: -private, +public, #protected, static, abstract Name (Schreibweise): smallCamelCase Reihenfolge: Sichtbarkeit Name ( Parameter1, Parameter2, ... ): Rückgabetyp Assoziationen: Benennung (Schreibweise): Deutscher Fließtext Multiplizität: 1, 0..*, n, n..m, ... Typen: Assoziation ("kennt"), Aggregation ("ist teil von"), Komposition ("ist abhängiger Teil von") Vererbung: Typen: stark ("erbt von"), schwach bei Interfaces/Traits ("bindet ein")
Schwierigkeiten:	Die Erstellung von Klassendiagrammen gehört zu den grundlegenden Aufgaben, die auch in praktisch jedem Examen gefordert wird. Aus diesem Grund wird davon ausgegangen, dass entsprechende Aufgabentypen routiniert heruntergearbeitet werden können. Dies resultiert in oftmals relativ wenig Punkte für die häufig mühsame graphische Erstellung. Im Gegensatz zum didaktischen Klassendiagramm enthält das UML-Klassendiagramm zusätzliche Informationen und Klassen werden mit BigCamelCase (statt ALLCAPS) benannt.
Bsp.-Aufgabe:	Für ein [...] System an einer [...] soll ein [...]-Programm entworfen werden. Entwerfen sie ein UML-Klassendiagramm für folgendes Szenario: [...]

Sonstige UML-Diagramme

Häufigkeit:	Gelegentlich, viele unterschiedliche Ausprägungen
Inhalte:	Objektdiagramme: Unterschied zur didaktischen Notation (insb. eckige Kästen!) Aufgaben vertieft: F2012-T1-2a, H2017-T2-2b, F2018-T2-1c, H2018-T1-1 Aufgaben nichtvertieft: H2017-T1-2b Sequenzdiagramme: Pfeilarten: Asynchron, Synchron, Rückantwort Aktivitätsbalken: gesetzt oder nicht? Aufgaben vertieft: F2012-T1-3a, F2016-T2-4, F2017-T2-3, H2017-T1-3b-c, F2018-T2-1d, H2018-T1-3b Aufgaben nichtvertieft: F2013-T2-1b, F2015-T2-3b, H2016-T2-2 Use-Case-Diagramm: Auch: Anwendungsfalldiagramm Aufgaben vertieft: F2012-T2-4a, F2014-T2-4a, H2016-T1-2a, F2017-T1-3a Aufgaben nichtvertieft: F2013-T1-1b, H2014-T2-3a, F2017-T1-2 Zustandsdiagramm: Auch: Zustandsübergangsdiagramm Erweiterte Zustandsübergangsdiagramme: Enthalten auch Logik wie Fallunterscheidungen, Parallelität Hierachische Zustandsdiagramme: Ineinander geschachtelt Aufgaben vertieft: F2012-T1-3b, F2015-T1-2, H2015-T1-3, F2017-T1-4a, F2017-T2-3, H2017-T2-3d, F2018-T2-3, H2018-T1-2c Aufgaben nichtvertieft: H2014-T2-3d, H2015-T1-2, F2016-T1-3, H2016-T1-4, F2017-T2-4a, H2018-T1-3 Aktivitätsdiagramm: Elemente: Start, Ziel, Fallunterscheidung, Parallelität, Abfolgepfeil Aufgaben vertieft: F2012-T2-5c-d, H2012-T1-1b, F2014-T1-1b, F2014-T2-4b, F2016-T1-1b Aufgaben nichtvertieft: F2013-T1-1b
Schwierigkeiten:	Eine Großzahl an weiteren Diagrammen muss, in der richtigen formalen Schreibweise, beherrscht werden. Die einzelnen Diagramme werden zwar selten gefordert, sind aber auch selten sehr komplex.

Programmierung

Häufigkeit:	Meistens, Art und Umfang verschieden
Inhalte:	Programmieren in einer selbstgewählten, objektorientierten Programmiersprache: Syntaktisch korrektes Umsetzen von Klassendiagrammen in Code (inkl. Sichtbarkeiten, Vererbungen, Assoziationen, ...) Syntaktisch korrektes Umsetzen von Aktivitäs- und Sequenzdiagrammen in Code Syntaktisch korrekte Umsetzung von Design Patterns in Code Syntaktisch korrekte Deklaration von Klassen, Funktionen, Attributen, Variablen, und Enums Theoretisches Wissen zur Programmierung: Programmierparadigmen (insb. imperativ, objektorientiert, funktional, logisch/deklarativ) Programmier-Prinzipien (insb. Verständnis der SOLID-Prinzipien) Code-Analysen (Syntax vs. Semantik, Design-Richtlinien, Kommentierung und Dokumentation) Allgemeine Phänomene der Programmierung (APIs, Vererbungsarten, ...)
Schwierigkeiten:	Die Wahl der Sprache wird fast nie vorgegeben. Dennoch ist die Aufgabenstellung häufig auf eine spezifische Sprache optimiert. Dies ist meistens Java, war aber auch schon Haskell. Ohne Kenntnis dieser Sprache sind Theoriefragen (etwa zu verschiedenen Vererbungstypen, die v.a. in Java auftauchen) nur schwer zu beantworten. Auch wenn kleinere Syntaxfehler (vergessenes Semikolon) in der Korrektur üblicherweise nicht gewertet werden, sollte die grundlegende Syntax dennoch gut sitzen. Insbesondere der Aufbau und die exakte Syntax von Funktionen und Vererbungsstatements wird erwartet. Im Gegensatz zum Studium steht im Examen keine IDE zur Verfügung, die derartige Aufgaben automatisch und korrekt übernimmt. Es ist schwierig, sich auf die allgemeine Theoriefragen vorzubereiten. Diese sind zwar zumeist mit ein wenig Programmiererfahrung einfach zu beantworten, ohne diese sind die Aufgaben aber mitunter schwer.
Entwicklung des Aufgabentyps:	Zu Beginn war die Umsetzung kleiner- bis mittelgroßer Programme zentraler Bestandteil des SWT-Examens. Der Aufgabentyp ist mittlerweile seltener geworden und zielt nun stärker auf theoretische, für alle Programmiersprachen gültige Kenntnisse ab. Wenn Code gefordert ist, so beschränkt er sichin neueren Examen zumeistens auf wenige Zeilen bis etwa eine Seite.

Testen und Fehler

Häufigkeit:	Häufig, insbesondere in letzter Zeit
Inhalte:	Testgegenstände: Funktional: Funktionalität, Grenzwerttests, Crashtests, Kompatibilitätszests, Zufallstests (Fuzzing) Temporal: Komplexität (Algorithmus), Laufzeit (Code), Lasttest, Streßtest (Überlastung) White-Box-Tests: Testarten: Kontrollflussorientiert, Datenflussorientiert, Bedingungsorientiert Kontrollflussorientiert: Kontrollflussgraph (knotenorientiert, kantenorientiert), Boundary-Interior-Überdeckung, Anweisungsüberdeckung, Kantenüberdeckung, Pfadüberdeckung, strukturierte-k-Pfadüberdeckung, Mc-Cabe-Metrik (zyklomatische Komplexität) Datenflussorientiert: Def-Uses (p-, c-, def-use), All-p-some-c-Überdeckung (u.a.), Bedingungsorientiert: Bedingungsüberdeckung (einfach, minimal, mehrfach) Black-Box-Tests: Testarten: Äquivalenztests, Use-Case-Tests, paarweises Testen, Diversifizierende Verfahren (insb. Regressionstests) Testebenen: Unit-, Integrations- System-, und Abnahmetests Integrationsreihenfolge: Big-Bang (alles auf einmal), Strukturorientiert (Bottom-Up, Top-Down, Outside-In/"Sandwich"), Funktionsorientiert (Risiko, Termin, Funktionalität) Softwaremetriken Aufwandsorientiert: Mannstunden, Lines of Code Codeorientiert: Mc-Cabe (zyklomatische Komplexität), Lesbarkeit, Effizienz Prozessorientiert: Kosten, Erstellungsdauer, Entwickleranzahl, Risiko Kundenorientiert: Convenience, Aufwandersparnis, Schulungsaufwand, Zufriedenheit Fehlerarten, Fehlerbehebung, und Wartung: Fehlerursache, Fehlerzustand, Fehlerwirkung Fehlervermeidung, Fehlertoleranz korrigierende, adaptierende, und perfektionierende Anpassungen
Schwierigkeiten:	Das Themengebiet ist sehr umfangreich und lässt sich nur schwer eingrenzen. Sehr häufig werden einfache Verständnisfragen gestellt, auf die sich jedoch nicht gezielt lernen lässt.
Literatur:	Hoffmann: Software-Qualität (ISBN 978-3540763222, als E-Book im Katalog der Universität Würzburg vorhanden)

Formale Verifikation

Häufigkeit:	Gelegentlich, künftig hoffentlich seltener
Inhalte:	Deduktive Verifikation: Schritte: Vorbedingung, Schleifeninvariante, Nachbedingung, Terminierung Formalismen: Induktionsbeweise, Hoare-Kalkül, wp-Kalkül
Schwierigkeiten:	Es besteht Uneinigkeit darüber, in wie weit dieses Thema zum Themenbereich "Softwaretechnik und Datenbanken" oder "Algorithmen und Theoretische Informatik" gehört. Aus diesem Grund wird das Thema an einigen Universitäten (insb. Würzburg) nicht in der Softwaretechnikvorlesung behandelt. In anderen Vorlesungen werden die Inhalte angeschnitten, aber meistens nicht in Verbindung mit dem im Staatsexamen häufig geforderten Formalismus gelehrt. In einigen Prüfungen (H2013 und H2014) kam die formale Verifikation in beiden Themen vor. Ignorieren dieses Aufgabentypes ist daher nicht ohne weiteres möglich, zusätzliche Einarbeitung speziell für das Staatsexamen ist für diesem Aufgabentyp leider notwendig.
Literatur:	Hoffmann: Software-Qualität (ISBN 978-3540763222, als E-Book im Katalog der Universität Würzburg vorhanden)

Entwurfsmuster

Häufigkeit:	Gelegentlich
Inhalte:	Nennen und beschreiben üblicher Entwurfsmuster (Design Patterns): Erzeugungsmuster (creational patterns): Factory, Builder, Protoype, Singleton Strukturmuster (structural patterns): Adapter, Fassade, Decorator, Kompositum, MVC Verhaltensmuster (behavioral patterns): Observer, Visitor, Iterator, Template, Strategy, State, Umsetzen von Design-Patterns in Code (siehe Programmierung) Zeichnen von Klassendiagrammen zu bestimmten Design-Patterns
Schwierigkeiten:	Die Fragestellung zielt manchmal darauf ab, Beispiele an Mustern zu nennen, manchmal wird aber auch die Nennung der drei Kategorien gefordert. Dies ist häufig nur durch exaktes Lesen der Aufgabenstellung erkenntlich.