Embed Size (px)
Citation preview
Software Engineering
© Ludewig, J., H. Lichter: Software Engineering – Grundlagen, Menschen, Prozesse, Techniken. 2. Aufl., dpunkt.verlag, 2010.
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
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: BegriffePrinzip: 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 Spielenimmer deskriptiv; Modell hat Ähnlichkeit mit dem Original, die wir mit den Sinnen (Augen, Ohren, ....) wahrnehmen können.
● SESAM, Flugsimulatoren
b) Formale (mathematische) Modellemeist deskriptiv; oft in Modellen des Typs A enthaltenÄhnlichkeit mit dem Original ist nicht wahrnehmbar.
● eine Formel
c) Modelle für die Dokumentationimmer deskriptiv; dient der Überlieferung von Informationen
● Fotos und Fotoalben, Geschichtsbücher, Gerichtsprotokolle
● Buchungsbelege, Logbücher, Fehlerreports
● Aufzeichnungen einer Überwachungskamera
14
Ziele - 2d) 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 Software-Entwicklung 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 hin-sichtlich 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, Z-Spezifikation 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 Aus-druck 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-DiagrammDie 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.
36
Mathematik Software Engineeringkeine Beschriftung Knoten immer, Kanten oft beschriftet. Die
Beschriftung verknüpft den Graphen mit der übrigen Software.
(auch) ungerichtete Graphen
meist gerichtete Graphen; Kanten stellen Flüsse oder Kausalität dar.
Kanten arm an Information
Kanten sind oft beschriftet und haben damit wie die Knoten Identität. Evtl. mehrere Kanten für ein Paar von Knoten.
Kanten sind Relationen zwischen Knoten.
Speicherung als bipartiter Graph (Kanten werden wie Knoten behandelt).
Repräsentation als bipartiter Graph
Kanten mit Typ und/oder Identität:
Der Graph wird zur Speicherung in einen bipartiten Graphen über-setzt, die Knoten der einen Klasse repräsentieren die ursprüng-lichen 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 neben-sä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
46
Skalentyp Beispiel allgemein Beispiel Software Engineering
Nominalskala Nationalität, Geschlecht Programmiersprache, CASE-Tool
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 (Code-Zeilen),Fehlerzahl
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
