Modell des Modellseins - Professur Betriebssysteme

Betriebssysteme II - Analyse und Modellierung
Sommersemester 2017
Betriebssysteme II - Analyse und Modellierung
1. Kapitel
Modell des Modellseins
Dr. Peter Tröger
Professur Betriebssysteme
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.1 Modelle
1.1 Modelle
Modellbegriff
Modelltheorie von STACHOWIAK.
I
Drei Merkmale:
I Abbildungsmerkmal
I Verkürzungsmerkmal
I Pragmatisches Merkmal
I
Folgerung: Modelle sind als solche nicht per se zu betrachten (also was und wie
ein Modell Eigenschaften des bezogenen Systems beschreibt), sondern auch im
Kontext ihres Einsatzes, d.h. wie und warum Modelle in Beziehung zur Realität
gesetzt werden
I
Anders ausgedrückt: Es muss stets berücksichtigt werden, welche Frage an ein
Modell gestellt werden sollen
SoSe 2017 · P. Tröger
2 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.1 Modelle
Einige Aspekte der Modellnutzung
Implementation
Verification
Release
Support &
Servicing
WhiteboxModell
Design
Requirements
Entwicklungszy
klus
BlackboxModell
Modellbildung
Einführungsphase
Wachstumsphase
Graybox-Modell
Software
Entwicklung
Lebenszyklus
Geschäftsprozess
Modellierung
Nutzung des
Modells
Reifephase
Einsatzdomäne
Entwicklung
elektronische
Systeme
Sättigungsphase
Modellzweck
Degenerationsphase
Tool-Unterstützung
Vorgehensmodellierung
Konstruktiv
(Modell für ...)
Editor
Simulationswerkzeug
SoSe 2017 · P. Tröger
Transformationswerkzeug
Abbildend
(Modell von ...)
Analysewerkzeug
3 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.1 Modelle
Modellerstellung und -nutzung
I
Prinzipiell ist man bei der Nutzung von Modellen frei
I
Aber: Man muss sich stets über (evtl. implizite) Konsequenzen im Klaren sein
I Verkürzung (Abstraktion) und Abbildung beruht stets auf Modellannahmen
I Rückschlüsse auf die Realität sind durch diese Modellannahmen begrenzt!
I Besonders kritisch bei nichtformalen Modellen: diese bringen die Gefahr der
Mehrdeutigkeit mit sich
SoSe 2017 · P. Tröger
4 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.1 Modelle
Was modellieren?
I
Was soll modelliert werden?
Aussage von Michael A. Jackson, 1974
Zu modellieren ist nicht nur
I
what must be build – „the machine“
I
sondern auch what is given – „the problem domain“
I
Nur so werden die Zusammenhänge sichtbar!
SoSe 2017 · P. Tröger
5 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.1 Modelle
Was modellieren: Beispiel Betriebssystem
I
Prozessmanagement
I Scheduling und Schedulingstrategien
I Prozessinteraktion, Synchronisation
I
I
Ressourcenmanagement
I Belegungsstrategien
I Konfliktlösungsstrategien
I
I
zu untersuchende Eingenschaften: Ausführbarkeit, Performance, ...
zu untersuchende Eingenschaften: Verklemmungsfreiheit, Fairness,...
Schutzfunktion
I Zugriffsrechte
I Policies
I
zu untersuchende Eingenschaften: Sicherheit, ...
SoSe 2017 · P. Tröger
6 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.1 Modelle
Warum modellieren?
I
Modelle (Abstraktionen) helfen der Kommunikation
I Wenn jemand vom Man-in-the-middle-Angriff spricht, ist klar, was gemeint
ist
I
Konstruktion:
I Modelle dienen als Blaupause für die Schaffung von Systemen
I
Analyse:
I Erkenntnisse über Systeme gewinnen (Eigenschaften bestimmen)
I
Die Vorlesungsreihe widmet sich insbesondere dem letzten Aspekt
SoSe 2017 · P. Tröger
7 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.1 Modelle
Was kann schiefgehen?
Input
Parameters
Real World
Systems
Parametric Errors
• Different component parameter sources
• Projected stress factors assume unrealistic
operational conditions
Solution
Technique
Model
Modeling Errors
• Structural Errors: Initial state,
missing or extra states / transitions
• Error Propagation Model
• Parametric Models: Failure and repair rates,
coverage parameters
• Errors dueSystems
to non-independence
Dependable
Course
Solution Errors
• Approximation Errors: System partition, state aggregation
• Numerical Errors: Truncation, Round-off
• Programming Errors
• Estimation Errors: Stochastic estimators, not enough data
State-Based Modeling | Dependable Systems 2014
SoSe 2017 · P. Tröger
Evaluations
8 / 26
34
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.1 Modelle
Beispiel: Periodisches Taskmodell
I
Echtzeitsscheduling: RMS und EDF benutzen beide die Standardannahmen für
das periodische Taskmodell:
1. Jede Task wird periodisch neu gestartet (Taskinstanzen)
2. Jede Taskinstanz muss beendet sein, ehe die nächste beginnt á Deadline =
Periode
3. Eine Task ist vollständig unabhängig und hat (mit Ausnahme des
Prozessors) jederzeit hinreichende Ressourcen
4. Task sind jederzeit unterbrechbar
5. Umschaltzeiten sind vernachlässigbar
SoSe 2017 · P. Tröger
9 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.1 Modelle
Diskussion der Modellannahmen
I
Modellannahme 1 (Periodizität) ist meist gegeben
I
Modellannahme 2 (Deadline = Periode) abstrahiert (u.a.) von „Aufräumarbeiten“
nach Ausgabe des Steuerbefehls
I
Modellannahmen 3 (Unabhängigkeit) und 4 (Unterbrechbarkeit) gelten nicht
allgemein und müssen sichergestellt werden
I Unabhängigkeit von Ergebnissen anderer Tasks kann durch entsprechende
Modularisierung erreicht werden
I Hinreichende Ressourcen sind nur möglich, wenn z.B. keine zwei Tasks die
gleiche E/A benutzen á kritischer Abschnitt
I
Annahme 5 ist eine Abstraktion á darauf beruhende Aussagen sind
Grenzaussagen
I Umschalten konsumiert immer Zeit, Modell setzt diese aber auf Null!
SoSe 2017 · P. Tröger
10 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.1 Modelle
Diskussion der Modellannahmen (Forts.)
I
Aussagen über EDF, die auf dem Modell beruhen:
1. „Jede Taskmenge, deren Last ≤ 1 ist, ist erfolgreich planbar.“
2. „EDF ist optimal.“
I
Echtzeit-Systeme
Prozessorzuteilung
Aussage 1 gilt (u.a.) nur
unter Annahme 5: In der Praxis läßt man
daher stets
einen „Sicherheitsabstand“
Aussage 2 gilt z.B. nicht, wenn Annahme 4 gilt
I Gegenbeispiel: 3 Jobs Ji (tr , e, D) J1 (0, 3, 10), J2 (2, 6, 14), J3 (4, 4, 12)
I EDF:
I
Echtzeit-Systeme
Prozessorzuteilung
J
J
J
J 22
J 11
J 33
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 tt
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Deadline
Deadline
verpaßt!
verpaßt!
I
Non-EDF:
Abbildung 14: durch EDF generierter (ungültiger) Schedule
Abbildung 14: durch EDF generierter (ungültiger) Schedule
J
J
J
J 11
J 33
J 22
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
SoSe 2017 · P. Tröger
t
t
Abbildung 15: gültiger Schedule (nicht durch EDF generiert)
26
osg.informatik.tu-chemnitz.de
Abbildung11
15:/ gültiger
Schedule (nicht durch EDF
generiert)
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.2 Techniken
1.2 Techniken
I
Prinzipiell: Der Modellierer kann sich die geeignete Methode aussuchen
I
Betrachten zwei (hoffentlich!) bekannte Modellierungsmethoden
I UML
I Graphen
SoSe 2017 · P. Tröger
12 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.2 Techniken
Methodenbeispiel: UML
I
Aus dem SW-Engineering-Ansatz der Objektorientierung entstanden
I
In Entwicklung, aktuelle Version 2.5 (Juni 2015)
SoSe 2017 · P. Tröger
13 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.2 Techniken
Methodenbeispiel: UML (Forts.)
I
UML kennt 13 Diagrammarten
I 6 Strukturdiagramme
I 7 Verhaltensdiagramme
I
Diese Diagramme benutzen eine Reihe von Sprachelementen
I Dinge (things)
I Beziehungen (relationships)
I Diagramme (diagramms)
I
Sprachelemente können andere Sprachelemente nutzen
I
Gleiche Sprachelemente werden von verschiedenen Diagrammarten genutzt
á Diagrammarten stellen verschiedene Sichten auf ein System dar
SoSe 2017 · P. Tröger
14 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.2 Techniken
UML-Diagramm: Klassendiagramm
I
I
Zusammenstellung deklarativ-statischer Modellelemente (Klassen, Typen,
Beziehungen)
Strukturdiagramm, Basis des UML-Metamodells
SoSe 2017 · P. Tröger
15 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.2 Techniken
UML-Diagramm: Anwendungsfall
I
Darstellung der Funktion des Gesamtsystems aus Sicht der beteiligten Akteure
(Anwender)
I
Verhaltensdiagramm
SoSe 2017 · P. Tröger
16 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.2 Techniken
Methodenbeispiel: Graphen
I
Nur zwei Entitäten: Knoten und Kanten
I
Einfache grafische Darstellung
(zumindest, solange es keine Hypergraphen sind)
á Einfache Abbildung
SoSe 2017 · P. Tröger
17 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.2 Techniken
Vergleich
UML
Graphen
I
semi-formal
I
formal
I
Syntax (weitgehend) präzise
I
präzise1 Syntax
I
Semantik (zum Teil) unpräzise
I
präzise Semantik
I
weniger abstrakt
I
sehr abstrakt
I
leichter zu implementieren
I
leichter zu analysieren
1 aber nicht immer einheitliche
SoSe 2017 · P. Tröger
18 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.2 Techniken
Formale Modelle in der Informatik
I
Vielzahl von Beispielen für formale Modellierungsansätze:
I
Graphen
I Vererbungsgraphen,
Abhängigkeitsgraphen, etc.
I
Prozessalgebren
I CSP und Co.
I π-Kalkül und Co.
I
Stochastische Modelle
I Warte-Schlangen
I Markow-Ketten
I
I
Automatenmodelle
I Endlicher Automaten
I Zelluläre Automaten
Temporallogiken
I LTL, CTL
I Zeitbehaftete
Temporallogiken
I
Berechnungsmodelle
I Turingmaschine
I λ-Kalkül und Co.
Aktive Netze
I Petri-Netze
I Aktivitätsnetze
I
...
I
SoSe 2017 · P. Tröger
19 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.2 Techniken
Formale Methoden
Was macht sie aus?
I
Techniken der Logik und der Diskreten Mathematik, verwendet um
Computer-Systeme und Software zu spezifizieren, entwerfen und zu beschreiben
I
Komplexität meistern durch Abstraktion
I
Über Eigenschaften reden in einem Kalkül, rechnergestützt überprüfbar
I
Projektreviews ersetzen durch wiederholbare Analyse
I
Formale Methoden kann man verwenden auf verschiedenen Abstraktionsebenen
SoSe 2017 · P. Tröger
20 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.2 Techniken
Formale Methoden (Forts.)
Wann werden Sie im Software-Entwicklungsprozess verwendet?
I
wenn man gar nicht mehr weiterkommt
wenn das Risiko eines Fiaskos wächst
I
wenn die Beteiligten schon viel gelitten haben
I
wenn die Entwickler selber Zweifel kriegen
I
SoSe 2017 · P. Tröger
21 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.2 Techniken
Formale Methoden (Forts.)
... welche sind die „richtigen“?
I
Die Entscheidung für eine formale Methode ist immer strategisch
I
nicht eindeutig
I
Firmen wollen Werkzeuge verkaufen
I
„Formale Methode“ ist häufig ein Buzzword
I
„Formal“ ist im Grunde sinnleer
SoSe 2017 · P. Tröger
22 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.3 Anwendungsbeispiel: seL4-Kernel
1.3 Anwendungsbeispiel: seL4-Kernel
I
seL4: Variante des L4-Kernels mit formal bewiesenen Eigenschaften
á Übereinstimmung mit abstrakter Spezifikation, u.a.
I Terminierung aller Systemrufe
I Sicherheit im Zugriff auf kritische Ressourcen
I ...
I
Korrektheit der Implementation
Entwurf für Verifikation
I
Design Cycle
Design
Hardware
Simulator
+
Haskell
Prototype
Abstract Speci
Formal Executable Spec
Manual
Implementation
User Programs
SoSe 2017 · P. Tröger
Executable Spe
Proof
High-Performance C I
High-Performance C Implementation
Figure 1: The seL4 design process
23 / 26
Figure 2: The refin
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.3 Anwendungsbeispiel: seL4-Kernel
Refinement
I
HOL
schedule ≡ do
threads ← all_active_tcbs ;
thread ← select threads ;
switch_to_thread thread
od OR switch_to_idle_thread
I
Haskell
schedule = do
action <- getSchedulerAction
case action of
ChooseNewThread -> do
chooseThread
setSchedulerAction ResumeCurrentThread
...
chooseThread = do
r <- findM chooseThread ' ( reverse [ minBound .. maxBound ])
when ( r == Nothing ) $ switchToIdleThread
chooseThread ' prio = do
q <- getQueue prio
liftM isJust $ findM chooseThread ' ' q
chooseThread ' ' thread = do
runnable <- isRunnable thread
if not runnable then do
tcbSchedDequeue thread
return False
else do
switchToThread thread
return True
SoSe 2017 · P. Tröger
24 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
1.3 Anwendungsbeispiel: seL4-Kernel
Refinement (Forts.)
I
C
void setPriority ( tcb_t * tptr , prio_t prio ) {
prio_t oldprio ;
if ( thread_state_get_tcbQueued ( tptr - > tcbState ) ) {
oldprio = tptr - > tcbPriority ;
ksReadyQueues [ oldprio ] =
tcbSchedDequeue ( tptr , ksReadyQueues [ oldprio ]) ;
if ( isRunnable ( tptr ) ) {
ksReadyQueues [ prio ] =
tcbSchedEnqueue ( tptr , ksReadyQueues [ prio ]) ;
}
else {
thread_state_ptr_set_tcbQueued (& tptr - > tcbState , false ) ;
}
}
tptr -> tcbPriority = prio ;
}
SoSe 2017 · P. Tröger
25 / 26
osg.informatik.tu-chemnitz.de
Betriebssysteme II - Analyse und Modellierung – Modell des Modellseins
Literatur
Literatur
[Sta73]
Herbert Stachowiak. Allgemeine Modelltheorie. Wien, New York:
Springer-Verlag, 1973
[OMG12]
Object Management Group, Hrsg. Unified Modeling Language Version
2.5 FTF – Beta 1. 2012
b [Kle+10]
Gerwin Klein u. a. „seL4: Formal Verification of an Operating-system
Kernel“. In: Communication of the ACM 53.6 (Juni 2010), S. 107–115
SoSe 2017 · P. Tröger
26 / 26
osg.informatik.tu-chemnitz.de