Transcript Modell

Software Engineering
1 Modelle und Modellierung
1.1 Modelle, die uns umgeben
1.2 Modelltheorie
1.3 Ziele beim Einsatz von Modellen
1.4 Entwicklung und Validierung von Modellen
1.5 Modelle im Software Engineering
1.6 Theoriebildung
1.7 Modellierung durch Graphen und Grafiken
1.8 Modellierung durch Zahlen: Skalen und Skalentypen
1.9 Übergänge zwischen verschiedenen Skalentypen
© Ludewig, J., H. Lichter: Software Engineering – Grundlagen, Menschen, Prozesse, Techniken. 2. Aufl., dpunkt.verlag, 2010.
1.1 Modelle, die uns umgeben
Rolle von Modellen - 1
Modelle = fundamentales Konzept unseres Umgangs mit der Welt.
Nur der ständige Gebrauch von Modellen macht es möglich, dass
wir uns in der hochkomplexen Welt zurechtfinden.
Vgl. den Vorgang des Sehens und Erkennens:
● Das Hirn bekommt vom Auge einen „Teppich“ von Reizen.
● Daraus entsteht im Hirn ein Modell der Kanten.
Vorstellung des Volumens, der Masse, des Gewichts
● Dieses Modell wird weiter abstrahiert zur Abbildung auf einen
Begriff, mit dem wir anschließend arbeiten.
3
Rolle von Modellen - 2
Es entwickelt sich also eine Kaskade von Modellen.
Modelle sind für alle Wissenschaften und Techniken wichtig; im SE,
wo kein materielles Produkt entsteht, ist ihre Rolle fundamental.
Oft stellt in unserem Fach ein Modell das Endprodukt dar.
Die Wahrnehmung der Welt ist also durch Modelle, die wir
„mitbringen“, erheblich beeinflusst. Darum sehen verschiedene
Menschen in derselben Situation verschiedene Dinge.
Optische Täuschungen entstehen, wenn uns ein bestimmtes Modell
suggeriert wird, das für die konkrete Situation nicht geeignet ist.
In der Philosophie wurde dafür der Begriff des Paradigmas geprägt.
Ein Paradigma ist ein Modell, in das wir unsere Eindrücke
einpassen.
4
Beispiele für Modelle - 1
Lebenswichtig: Begriffe
Prinzip: Wir reduzieren Billionen von Eindrücken auf einige
Tausend Begriffe, über die wir in der Regel Kenntnisse haben.
Durch die Begriffe können wir die Welt auf die uns (überwiegend)
bekannten Muster reduzieren.
Beispiel
● Der Begriff Mensch steht für alle Menschen, denen wir begegnet
sind und zukünftig begegnen.
Problem aller Modelle
● Die Neigung, Modell und Realität zu verwechseln, d. h. die
Modelle nicht mehr als solche wahrzunehmen.
Dadurch führen uns Modelle auch in die Irre, wenn sie sich als
Vorurteile oder Klischees äußern.
5
Beispiele für Modelle - 2
Modelle sind uns so geläufig, dass wir sie in der Regel nicht mehr
als Modelle wahrnehmen: Jedes Bild, jedes Schema ist ein Modell.
Beispielsweise sind Modelle des Menschen
● ein Personen-Foto
● die anatomische Darstellung der Blutbahnen
● Strichmännchen und Piktogramme
● ein Steckbrief (mit oder ohne Bild)
● ein Fingerabdruck
● eine Matrikelnummer
Was wir als Modelle erkennen, sind vor allem solche, die optisch
oder sonst wie strukturell mit dem Original übereinstimmen. Das
muss aber nicht sein (vgl. Matrikelnummer, Fingerabdruck).
6
Modelle im Software Engineering
Software wird auf unterschiedliche Arten repräsentiert, typisch durch
● eine Spezifikation,
● Diagramme und Quellcode,
● Kennzahlen (Metriken),
● Prospekte.
Welcher Gegenstand ist eigentlich das Original?
● Diese Frage ist nicht eindeutig zu beantworten!
Arbeitsabläufe werden durch Prozessmodelle beschrieben. Gutes
Software Engineering ist weitgehend gleichbedeutend mit der Wahl
eines geeigneten Prozessmodells und seiner Umsetzung.
Jede Theorie ist ein Modell. Im Software Engineering steckt die
Theorie-Bildung noch in den Kinderschuhen!
7
1.2 Modelltheorie
Deskriptive und präskriptive Modelle
Modelle sind entweder Abbilder von etwas oder Vorbilder für etwas.
Ein Modell ist deskriptiv, wenn es ein (bestehendes oder gedachtes)
Objekt beschreibt.
● Zuerst gibt es das Original, dann das Modell.
● Beispiel: Foto
Ein Modell ist präskriptiv, wenn es dazu dient oder dienen könnte,
ein Objekt nach dem Modell herzustellen.
● Zuerst gibt es das Modell, dann das Original.
● Beispiel: Bauplan
9
Hinweise und Beispiele
Achtung: Prognostische Modelle sind deskriptiv, sie beschreiben
einen zukünftigen Zustand, sie fordern ihn nicht!
● Beispiel: Wettervorhersage, Kostenschätzung
Achtung: Ob ein Modell deskriptiv oder präskriptiv ist, kann man im
Allgemeinen nur entscheiden, wenn man die
Entstehungsgeschichte kennt; im Modell selbst steckt dieses
Merkmal nicht.
Beispiele:
● Eine Konstruktionszeichnung ist in der Regel ein präskriptives
Modell; gelegentlich wird aber auch ein Objekt, für das keine
Zeichnung existiert, durch eine Zeichnung beschrieben.
● Eine Architekturzeichnung kann deskriptiv oder präskriptiv sein.
● Aus einer Kostenschätzung kann eine Vorgabe werden.
10
Die Modelltheorie von Stachowiak - 1
Ein Modell entspricht dem Original in den meisten Fällen nicht
völlig. Dafür gibt es drei Gründe:
● Attribute des Originals fallen durch Abstraktion weg (präterierte
Attribute)
● Die Abbildung ins Modell ist mit einer Transformation verbunden.
● Das Modell weist Attribute auf, die nicht durch das Original
bestimmt sind (abundante Attribute).
11
Die Modelltheorie von Stachowiak - 2
Stachowiak (1973) hat dieses Schema durch drei so genannte
Modellmerkmale charakterisiert:
Das Abbildungsmerkmal
● Zum Modell gibt es das Original, ein Gegenstück, das wirklich
vorhanden, geplant oder fiktiv sein kann.
Das Verkürzungsmerkmal
● Ein Modell erfasst nicht alle Attribute des Originals, sondern
nur einen Ausschnitt.
Das pragmatische Merkmal
● Modelle können unter bestimmten Bedingungen und bezüglich
bestimmter Fragestellungen das Original ersetzen.
12
1.3
Ziele beim Einsatz von Modellen
Ziele - 1
a) Einsatz in der Lehre / zum Spielen
immer deskriptiv; Modell hat Ähnlichkeit mit dem Original, die wir
mit den Sinnen (Augen, Ohren, ....) wahrnehmen können.
● SESAM, Flugsimulatoren
b) Formale (mathematische) Modelle
meist deskriptiv; oft in Modellen des Typs A enthalten
Ähnlichkeit mit dem Original ist nicht wahrnehmbar.
● eine Formel
c) Modelle für die Dokumentation
immer deskriptiv; dient der Überlieferung von Informationen
● Fotos und Fotoalben, Geschichtsbücher, Gerichtsprotokolle
● Buchungsbelege, Logbücher, Fehlerreports
● Aufzeichnungen einer Überwachungskamera
14
Ziele - 2
d) Explorative Modelle
● Erst deskriptiv, dann (nach Erweiterung) präskriptiv. Folgen
einer gedachten Änderung der Realität sollen beurteilt werden.
Die Änderung wird darum im Modell durchgeführt.
Sehr viele scheinbar präskriptive Modelle sind tatsächlich explorativ.
Beispiele
● Modell eines Hauses; Spezifikation mit Ist- und Soll-Analyse;
Prototyp einer Software
15
1.4
Modell-Entwicklung und
Validierung
Entwicklung eines Modells
Modelle, auch die des Software Engineerings, entstehen durch
Beobachtungen, Analogieschlüsse und Intuition.
Beispiel
● Wer beobachtet, dass Programme in Programmiersprache A
typisch weit weniger syntaktische Fehler enthalten als solche in
B, hat eine Theorie entwickelt.
● Er schafft ein Modell, indem er postuliert, dass es (unter
bestimmten Bedingungen) in Sprache A im Mittel FA Fehler pro
1000 LOC gibt, bei Sprache B im Mittel FB.
Die Entwicklung von Modellen ist der Zweck jeder Forschung.
17
Validierung eines Modells - 1
Wer ein neues Modell vorschlägt, sollte es zunächst validieren.
Das geschieht (wie in den Naturwissenschaften) durch Experimente
und Beobachtungen.
Experiment
Eine (in der Regel nutzlose) Aufgabe wird von mehreren Probanden
(Personen oder Gruppen) bearbeitet.
Die Veranstalter des Experiments sorgen dafür, dass alle Probanden
unter gleichen Bedingungen arbeiten, mit einer Ausnahme: In einem
Punkt arbeiten sie mit verschiedenen Bedingungen. Dieser Aspekt
wird im Experiment untersucht.
18
Validierung eines Modells - 2
Beobachtungen
Bei Beobachtungen (Feldstudien) untersucht man aktuelle oder
dokumentierte Abläufe, meist Software-Projekte oder Teilprojekte.
Problem der Experimente: drei sehr große Hindernisse
● Starker Einfluss der beteiligten Personen („Probanden“), dadurch
sehr große Streuung. Folge: statistische Aussagen nur mit vielen
Personen zulässig. Das ist extrem teuer!
● Probanden (meist Studenten) sind oft nicht typisch für die, über
die Aussagen gemacht werden sollen (meist Praktiker).
● Die zu klärenden Fragen müssen präzise gestellt werden, um das
Experiment reproduzierbar zu machen. Dann sind aber die
Ergebnisse nur für einen winzigen Ausschnitt der Welt gültig.
19
Validierung eines Modells - 3
Problem der Feldstudien: Einflüsse nicht überschaubar
In der Praxis gibt es praktisch nie zwei Projekte, die unter sehr
ähnlichen Bedingungen durchgeführt werden.
Dabei ist zu befürchten, dass die Projekte durch andere Einflüsse, z.
B. die Zusammensetzung der Entwicklergruppen, Unterschiede der
Aufgaben und Rahmenbedingungen usw. erheblich geprägt sind.
20
Validierung eines Modells - 4
Beispiel 1: Wie wirkt sich die Methode der Entwicklung aus?
● Die Effekte einer bestimmten Vorgehensweise bei der SoftwareEntwicklung sollen festgestellt werden.
● Experiment: n Entwicklergruppen; n/2 Gruppen entwickeln nach
Methode A, n/2 nach Methode B. Probanden (i. d. R. Studenten)
werden den Gruppen durch Los zugeordnet. Vorkenntnisse hinsichtlich A und B sollten völlig gleich sein (das ist kaum zu
schaffen).
Beispiel 2: Boehm, Gray, Seewald (1984)
● Entwicklung eines Programms durch viele Studentengruppen,
teils mit Spezifikation, teils mit Prototyping. In diesem Fall waren
viele Voraussetzungen nicht erfüllt.
21
1.5
Modelle im Software
Engineering
Einsatz von Modellen
Die Anwendung des Modell-Begriffs auf Software zeigt, dass wir fast
nur mit (oft mehrstufigen) Modellen arbeiten.
● Vorstellungen des Kunden → Software-Spezifikation
● Code → ausführbares Programm → Ausführung
Viele Modelle werden als Graphen dargestellt.
Auch ein Balkendiagramm mit der Rechenzeit verschiedener
Algorithmen ist ein Modell, wobei das Original die Rechenprozesse
sind, deren Attribute bis auf Bezeichner und Rechenzeit präteriert
sind. Die Form (Balkendiagramm) ist abundant. Ähnliches gilt für alle
Metriken.
23
Software- und Prozessmodelle
Software-Modelle
● Freitext-Spezifikation, SADT-Diagramm, Use-Case-Diagramm, ZSpezifikation eines Moduls
Vorgehens- und Prozessmodelle
● Wasserfallmodell, Prototyping, V-Modell
Den Unterschied zwischen deskriptiven und präskriptiven
Modellen beachten!
● Präskriptive Modelle (Regeln, Richtlinien), die nicht beachtet
werden, sind nicht nur nicht nützlich, sondern schädlich, weil sie
bewirken, dass Regelungen generell chancenlos sind.
● Deskriptive Modelle (nüchterne Beschreibungen der Risiken,
des Entwicklungsstands, der Aufwands- und Terminschätzungen)
wären oft sehr nützlich, sind aber nicht populär.
24
1.6 Theoriebildung
Theoriebildung - 1
Wir entwickeln laufend Theorien, z. B. beim Bemühen, Fehler zu
lokalisieren und zu beheben.
Eine Theorie ist ein Modell, das Phänomene des Originals erklärt.
● Beispiel: Relativitätstheorie = Modell bestimmter physikalischer
Phänomene, erklärt Zusammenhänge zwischen Masse, Energie,
Raum und Zeit.
Eine Theorie wird als richtig (eigentlich: brauchbar) betrachtet, wenn
das pragmatische Merkmal möglichst umfassend gegeben ist.
● Beispiel: Die Relativitätstheorie erlaubt es, Aussagen über das
Licht zu treffen, die sich experimentell bestätigen lassen (etwa die
Ablenkung des Lichts durch Gravitation). Richtigkeit ist kein
konstantes Merkmal: Jede Theorie wird obsolet, wenn eine
bessere gefunden ist.
26
Theoriebildung - 2
Die sog. exakten Wissenschaften sind dadurch gekennzeichnet,
dass ihre Theorien ganz überwiegend formalisiert sind, ihren Ausdruck in Formeln finden.
● Die Formel für den Fallweg im Vakuum ist eine solche
formalisierte (und quantifizierte) Theorie:
s = g/2 t2
● Der zweite Hauptsatz der Thermodynamik ist (in seiner
allgemeinen Form) nicht quantifiziert, aber formalisiert:
ds/dt ≥ 0
27
Theoriebildung - 3
Die nicht-exakten Wissenschaften arbeiten mit nicht-formalen
Theorien: Die Arbeiten von Darwin zur Evolution und die Arbeiten
von Freud und Jung zur Psychologie enthalten viele solcher
Theorien.
Brooks‘ Law “Adding manpower to a late project makes it even
later” ist ebenfalls eine Theorie, typisch für viele Theorien im SE.
● weder formal noch präzise
● entspricht aber der Erfahrung
Manche solche Theorien haben sich aber als falsch erwiesen.
28
1.7
Modellierung mit Graphen und
Graphiken
Modellierung mit Graphen
Ingenieure haben schon immer vorzugsweise mit einfachen
Zeichnungen gearbeitet. Darum spielen Graphen, also Gebilde aus
meist beschrifteten Knoten und Kanten, im Software Engineering
eine besonders wichtige Rolle.
Graphen im Software Engineering
● Wenn wir im Software Engineering Graphen verwenden, so sind
diese in der Regel gerichtet und die Knoten sind beschriftet.
● Die Graphen sind oft hierarchisch aufgebaut, d. h., Knoten der
einen Ebene repräsentieren Graphen der nächsten Ebene.
● Kanten werden nicht immer in der üblichen Form als Linien
dargestellt, sie ergeben sich oft durch die Anordnung der Knoten.
● Grafische Merkmale werden verwendet, um verschiedene Typen
von Knoten, evtl. auch Kanten, zu unterscheiden.
30
Beispiel – Schichtenmodell
Die Knoten sind nur durch die Texte erkennbar (sie sind also beschriftet); die
(gerichteten) Kanten sind implizit durch die Anordnung der Knoten
angegeben.
31
Beispiel – Wasserfallmodell
Die Knoten des gerichteten Graphen sind beschriftet.
Es gibt zwei Arten von Kanten (mager und fett dargestellt).
32
Beispiel – UML Klassendiagramm
Die Knoten besitzen eine ausgeprägte Substruktur (d. h., die Knoten bilden
hierarchisch untergeordnete Graphen)
Verschiedene gerichtete Kantentypen repräsentieren unterschiedliche
Relationen zwischen Knoten; analog gibt es verschiedene Knotentypen.
33
Beispiel – Petri-Netz
Gerichteter bipartiter Graph (Stellen und Transitionen).
Die Stellen sind mit beliebig vielen Marken besetzt.
34
Beispiel – Struktogramm
Nassi-Shneidermann-Diagramm
Die Knotentypen des hierarchischen Graphen sind durch ihre Strukturen
unterschieden. Die gerichteten Kanten sind nur implizit.
35
Graphen in der Mathematik und im SE
Im Software Engineering verwenden wir Graphen praktisch
niemals so, wie sie in den Büchern über Graphentheorie gezeigt
werden.
Mathematik
keine Beschriftung
Software Engineering
Knoten immer, Kanten oft beschriftet. Die
Beschriftung verknüpft den Graphen mit
der übrigen Software.
(auch)
meist gerichtete Graphen; Kanten stellen
ungerichtete Graphen Flüsse oder Kausalität dar.
Kanten arm an
Kanten sind oft beschriftet und haben
Information
damit wie die Knoten Identität. Evtl.
mehrere Kanten für ein Paar von Knoten.
Kanten sind
Speicherung als bipartiter Graph (Kanten
Relationen zwischen werden wie Knoten behandelt).
Knoten.
36
Repräsentation als bipartiter Graph
Kanten mit Typ und/oder Identität:
Der Graph wird zur Speicherung in einen bipartiten Graphen übersetzt, die Knoten der einen Klasse repräsentieren die ursprünglichen Kanten, die der anderen die ursprünglichen Knoten.
(Nebeneffekt: Auch mehrstellige Relationen sind darstellbar.)
37
Weiterer wichtiger Unterschied
Für Mathematiker sind Graphen abstrakt, die Darstellungen nebensächlich.
Für Ingenieure ist das Bild wichtig, auch die (meist standardisierte)
Darstellung. Damit tragen auch Bildelemente, die formal gesehen
abundante Attribute sind, Bedeutung.
Vorstellung: Der größer dargestellte Knoten repräsentiert ein
größeres Programm oder eine schwierigere Aufgabe, die dick
gezeichnete Kante ist wichtiger als die gestrichelte usw.
Diese Konnotationen sind gefährlich, weil sie Aussagen suggerieren
können, die so nicht gemeint sind.
Konsequenz: Alle Attribute erklären oder auf Variationen nach
Möglichkeit verzichten oder notieren, dass unterschiedliche Attribute
ohne Bedeutung sind.
38
Spezielle Eigenschaften von Graphen
Gerichtete Graphen, die einen Baum bilden, sind im Software
Engineering oft besonders nützlich:
Ein Baum gestattet eine einfache Abstraktion: Jeder Teilbaum
(auch der ganze Baum) wird durch seinen Wurzelknoten
repräsentiert. Beispielsweise kann man – eine entsprechende
Baumstruktur vorausgesetzt – einen Programmteil abtrennen, indem
man seinen Wurzelknoten löscht.
Eine Hierarchie muss nicht unbedingt baumförmig sein.
Jede Halbordnung ist eine Hierarchie
39
Graphiken als Schaubilder
Weitläufig mit den Graphen verwandt sind Grafiken und Schaubilder
(meist zur Darstellung von Funktionen, beispielsweise die Zahl der
gefundenen Fehler als Funktion der Zeit).
40
Skizzen im Software Engineering
Gerade, wenn wir mit dem Rechner arbeiten, haben wir größte
Mühe, etwas Unscharfes auch unscharf erscheinen zu lassen.
41
1.8
Modellierung durch Zahlen:
Skalen und Skalentypen
Metrik
Eine Metrik (Kennzahl) ist ein Modell, bei dem die Verkürzung alle
Merkmale bis auf ein einziges beseitigt hat.
Ziel: knappe, möglichst klare und objektive Beschreibung einer
Software(-Komponente) oder eines Projekts.
Ansatz: quantifizierte Angaben, also (interpretierbare) Zahlen
Der Begriff Metrik bezeichnet das Verfahren, solche Zahlen zu
erheben, auch die Resultate der Erhebung.
43
Skalentypen - 1
Skalen sind eine wichtige Grundlage der Metriken
Skalen lassen sich unter der Relation „schließt ein“ selbst auf einer
(Ordinal-)Skala anordnen.
Eine Rationalskala bietet also alle Möglichkeiten der anderen Skalen
außer der Absolutskala (für die die Aussage nicht exakt gilt).
44
Skalentypen - 2
Nominalskala: Abbildung auf eine (ungeordnete) Menge
● Nur Prüfung auf Gleichheit! Das ist keine Skala im üblichen
Sinne.
Ordinalskala: Werte bilden eine geordnete Menge („Rangliste“)
● zusätzliche Operationen: Vergleich, Median und andere
Perzentilen
Intervallskala: Differenzen zwischen Bewertungen sind definiert
● zusätzliche Operationen: Differenzbildung, Mittelwert
Rationalskala: Es gibt einen natürlichen Nullpunkt
● zusätzliche Operationen: Quotientenbildung
Absolutskala: Einheit ist überflüssig, weil Zählung zu Grunde liegt
45
Skalentyp
Beispiel allgemein
Beispiel Software Engineering
Nominalskala
Nationalität, Geschlecht
Programmiersprache, CASETool
Ordinalskala
Reihenfolge des
Posteingangs
Skalentypen, CMMI-Skala
Intervallskala
Temperatur in Grad Celsius
Zeitpunkt (Datum und Uhrzeit)
Rationalskala
Masse, Druck, Stromstärke
Laufzeit, Aufwand
Absolutskala
Kapazität eines
Reisebusses,
Anzahl der Ferientage
Programmumfang (CodeZeilen),
Fehlerzahl
46
1.9
Übergänge zwischen
verschiedenen Skalentypen
Feststellung
Generell gilt:
● Eine Metrik kann man hinsichtlich der Skala nicht durch einen
Trick verbessern kann
● Die Kombination verschiedener Skalen bewirkt eine
Verschlechterung.
Wenn eine Ordinalskala beteiligt ist, dürfen wir nicht mehr rechnen!
● Diese Einschränkung ist sehr hinderlich, wenn wir verschiedene
Systeme, Komponenten oder Prozesse vergleichen wollen.
48
Wechsel auf eine schwächere Skala
Obwohl man auf der Intervall- und auf der Rationalskala den
Mittelwert bilden darf, verwendet man stattdessen gern den Median
● Dieser ist unempfindlich gegen »Ausreißer«, also Werte, die den
Mittelwert drastisch beeinflussen.
Beispiel
● Wir wollen Aussagen über die typische Größe der Module
gemessen in LOC machen (Absolutskala).
● Wir haben zehn Module mit je 100 LOC und eines mit 1200 LOC
● Nach Übergang auf die Rationalskala ist die mittlere Größe 200
LOC.
● Auch hier führt also ein »Ausreißer« zu einem falschen Eindruck.
● Ordnen wir die elf Module nach ihrer Größe und schauen auf den
mittleren (den sechsten), dann haben wir als Median 100 LOC.
49
Boxplots
Die Box umfasst die Quartilen,
der Querstrich kennzeichnet den
Median.
Die beiden durch Striche
begrenzten Bereiche oberhalb
und unterhalb der Box werden
als Whiskers (Fühler)
bezeichnet.
Sie markieren entweder die
Extremwerte oder die letzten
Werte, die nicht (nach einem
definierten Kriterium) als
Ausreißer eingestuft werden.
Die Ausreißer werden dann als
einzelne Punkte markiert.
50