# Sicherheitanalyse
- Grundverständnis von Sicherheitanalyse, er wird mit sicherheit keine Gefahrenanlyse verlangen.
- Grundverständnis gilt für den gesamten ersten Bereich, wir werden sicher kein Use-Case Diagramm zeichnen.
- Wie sieht ein Typischer Desingprozess aus, V-Modell.
# Sequenzdiagramme
- Mehr konkretes als bei 1.
- Automatenabwicklung sollten wir hinbekommen
- Semantik, Trace Semantik
- Timer erweitern sollte man hinbekommen.
- Sequenzdiagramme semantisch formulieren. Nur für die klaren sachen.
- Alles was mit der partiellen Ordnung zu tun hat sollte man können.
## Verifikation für Sequenziagramme
- Produktautomaten machen.
- Erreichbarkeit von Pfaden in den Produktautomaten zeigen.
# NEW SMV
- Syntax müssen wir nicht versthen
- Implementierungsrelation, was bedeutet hier eine Implikation? warum haben wir die Formeln so aufgeschrieben, dass die linke Seite immer wahr werden muss und die Rechte falsch?
- Grundverständnis um einen Beweis führen zu können, das verstehen was die Maschinerie macht um es theoretisch auch auf einem Blatt machen zu können
# Architekturdesign
- Grob verstehen warum man Sysml verwendet und nich was anderes
# Automaten
- State Charts.
- Semantik der Automaten (verschiedne Modelle!)
- State Charts verstehen
- AND Zustände auflösen und Blablabla Zustände auflösen.
- Alles was irgnedwas komplexeres beschreibt sollte man auflösen können
# Umgebungsmodellierung und Regler
- Wird nur oberflächlich abgefragt
- Man sollte wissen was der  unterschied zwischen Steuerung und Regelung ist
- Keine Physikalischen Gleichenung. Nur das priinzip dahiter (alles wird numerisch gemacht)
# Requirement engineering
- Kommt nicht dran
- Das einzige was er abfragen könnte: Wie macht man Requirments: Wording, Eindeutigkeit, Testzuordnung
# Unfallanalyse
- Wird er nicht konrekt am Beispiel in der Klausr machen
- Nur erklären wie das ganze funktioniert und was hat das für Einflüsse auf den Prozess