1 Was Ist Software Engineering

SOFTENG WS 07/08 Dirk Busse
1. Was ist Software – Engineering?

Problemstellung und Ziele der Vorlesung
Voraussetzung: Progra I; Progra II; eventuell Java

Î Vorher: Programmieren im Kleinen:
0 < 40 Zeilen; max. 100 Zeilen
Î Jetzt: Wie kann man Programme dieser Größenordnung entwickeln?
Wo liegen die Unterschiede?

‐ Größe:
Maße: ‐ Anzahl Zeilen (LOC)
‐ Anzahl Funktionen
‐ Anzahl Daten (Funktion Points)
‐ Komplexität:
Komplexe Softwaresysteme setzen sich aus vielen Komponenten (Teile) zusammen.
Es gilt: „Das Ganze ist mehr als die Summe seiner Teile.“
Maß: Anzahl der Schnittstellen
‐ Entwicklung im Team
Abstimmung, Aufgabenverteilung, (Standardisierung), Verwaltung unterschiedlicher
Entwicklungsstände (CVS=Concurrent Versions System), Mitarbeiterfluktuation
‐ Qualitätsauflagen
‐ Einhaltung von Budget (Personal‐ / Sachmittel)
‐ Wartungsverpflichtung
Zentrale Fragen:
Wie kann man komplexe Softwaresysteme erfolgreich entwickeln?
Welche Methoden, Werkzeuge, Standards,… kann man verwenden?
Grundlegende Begriffe:
Software:
Programm, Prozedur, Regeln und Daten sowie die dazugehörigen Dokumentationen, die im
Zusammenhang mit dem Betrieb eines Rechnersystems stehen.
Arten: Anwendungssoftware (Office, SAP,…), Systemsoftware (OS, DB, Treiber, …)
Software – Engineering:
Fachgebiet der Informatik – Bereitstellung und systematische Verwendung von Methoden und
Werkzeugen für arbeitsteilige, ingenieursmäßige Entwicklung und Anwendung von umfangreichen
Softwaresystemen.
Ziele:
1) Erfolgreiche Entwicklungen komplexer Softwaresysteme in der erforderlichen Qualität unter
Berücksichtigung der gegebenen Ressourcen.
2) Steigerung der Produktivität und Qualität in der Software – Entwicklung.
1
Software – Projekt:
‐ Zielgerichtete, einmalige Aufgabe
‐ Zeitbegrenzung (Start‐ / Endtermin)
‐ Kostenbegrenzung (Sach‐ / Personalmittel)
‐ Zusammenwirken unterschiedlicher organisatorischer und fachlicher Einheiten
Es gibt unterschiedliche Software – Projekte:
‐ Neuentwicklung, Weiterentwicklung,
‐ Upgrade – Projekt, Reengineering
Software – Qualität:
Gesamtheit der Merkmale und Merkmalswerte einer Software, die sich auf deren Eignung beziehen,
die definierten Eigenschaften zu erfüllen
Norm: ISO / IEC 9126
‐ Funktionalität
‐ Zuverlässigkeit
‐ Benutzbarkeit
Topebene
‐ Effizienz
‐ Änderbarkeit
‐ Übertragbarkeit
Software – Lebenszyklus:
Engl. Software Life Cycle
Lebenslauf einer Software von Entwicklungsbeginn über Nutzung bis zur Außerbetriebnahme.
2. Vorgehensmodelle:
Einfache Definition:
Strukturierte Anleitung für die systematische Bearbeitung von Software – Projekten. Muster für die
Beschreibung des Entwicklungsprozesses von Softwaresystemen.
Ziele: Software – Entwicklungsprozess soll:

‐ planbar
‐ nachvollziehbar
‐ kontrollierbar
‐ und lehrbar sein
Grundidee:
Gibt vor
Vorgehensmodell
Rollenmodell definiert Regeln Methoden u. Werkzeuge
wird ausgeführt von wird verwendet für
2
Aktivitäten / Ergebnisse
Meistens: ‐ Phasenmodell
Modelle unterscheiden sich hinsichtlich:

‐ Detailierungsgrad
‐ Folge, Wiederholung der Phasen
‐ Einbindung der Benutzer
‐ …
Grundlegende Phasen:
‐ Analyse
Ermittlung der Anforderungen (Ideen, Wünsche, …)
Kosten‐ / Nutzenanalyse
Ergebnis: Anforderungsspezifikation (Lastenheft, Pflichtenheft)
‐ Entwurf (Design)
Zerlegung in Komponente zur Bewältigung der Komplexität
‐ Festlegung der inneren Struktur der Software (Softwarearchitektur)
‐ Spezifikation der Komponenten (Funktionalität, Kommunikation)
Ergebnis: Softwarespezifikation
‐ Implementierung (Realisierung, Umsetzung)
Implementieren der Komponenten
Programmieren im Kleinen“
Ergebnis: Programm und Dokumentation
‐ Test
Fehlerbeseitigung
Einzeltest der Komponenten
Test des Gesamtsystems
…
Ergebnis: Testprotokoll, …
‐ Betrieb
Inbetriebnahme
Nutzung des Programms
Beispiele für Vorgehensmodelle
Î Wasserfallmodell
weitverbreitet (etwa 1970)
Analyse
Entwurf
Implementierung
Test
Betrieb
3
4
‐ Phasen werden nacheinander abgearbeitet

‐ In der Ur‐Form sind keine Rücksprünge vorgesehen
Î sequentielles Vorgehen
Vorteile:
‐ einfach
‐ Phasenmodell => Reduktion der Komplexität
‐ Entwicklungsfortschritt ist einfach zu überwachen
Nachteile:
‐ Anforderungen müssen „klein“ sein
Î Phasen müssen wiederholt werden
‐ Testphase liegt am Ende
‐ …
Î Erweiterung des Wasserfallmodells
Prototypentwicklung
Analyse
Entwurf
Implementierung
Test
Betrieb / Wartung
‐ Phasenmodell mit Prototypentwicklung

‐ Rückkehr in vorangegangene Phasen während der Entwicklung möglich, wenn bei einem höheren
Detaillierungsgrad Fehler früherer Phasen entdeckt werden
‐ Rückkehr in vorangegangene Phasen aufgrund von entdeckten Fehlern während der Wartung ist
möglich
‐ Prototyp wird nach Analysephase entsorgt
5
Evolutionäre Software – Entwicklung

Anwendung falls die Anforderungen unsicher, unscharf sind
Idee: Prototyp nicht wegwerfen, sondern analysieren und weiterentwickeln bis zum fertigen System
Planung
&
1. Produktdefinition
Prototyperstellung
Validierung
Auslieferung Modifikation der
Betriebe Ist neuer Prototyp erforderlich? Produktdefinition
nein ja
Wartung
Software – Entwicklung ist eine Frage von Entwicklungszyklen (iteratives Vorgehen/Schleife)

‐ Beginn mit den Kernanforderungen
‐ Prototypentwicklung umfasst Entwurf, Implementierung und Test
‐ Validierung liefert Verbesserungsvorschläge von Nutzern, die dann in die nächsten Zyklen
einfließen.
‐ Evolutionärer Prototyp wächst
‐ Inkrementelles Wachstum, falls der Prototyp unvollständig ist (fehlende Funktion)
‐ evolvierend, falls der Prototyp nicht konsistent, nicht angemessen, ist
Probleme:
‐ Überwachung ist schwieriger
‐ Modifikation der Produktdefinition kann unter Umständen nicht mehr als Erweiterung /
Änderung realisiert werden, sondern nur noch über eine grundlegende Änderung des
Gesamtsystems.
Î Inkrementelle Software – Entwicklung

ähnlich zur evolutionären Software Entwicklung
stückweise Realisierung:
‐ Beginn mit den Kernanforderungen, die notwendig sind, um ein lauffähiges System zu haben.
Unterschied zur evolutionären Software – Entwicklung:
‐ Analyse des Gesamtsystems zu Beginn der Entwicklung
‐ Inkrementelles Vorgehen
Partizipative Software Entwicklung:
‐ starke Einbeziehung der Nutzer in den Entwicklungsprozess
Vorgehensmodelle: RUP (Rational Unified Process)

V – Modell
Spiralmodell
6
1. Übung
Aufgabe 1
In der Vorlesung wurden verschiedene Merkmale zur Bewertung der Qualität einer
Software (ISO/IEC) angegeben. Formulieren Sie geeignete Definitionen:
a) Funktionalität
Richtigkeit, Angemessenheit, Sicherheit, Interoperabilität, Ordnungsmäßigkeit
Angemessenheit: Merkmale von Software, die sich auf das Vorhandensein und die Eignung
einer Menge von Funktionen für spezifizierte Aufgaben beziehen.
ANMERKUNG: Beispiele für Eignung sind auf aufgabenorientierte
Zusammensetzungen von Funktionen aus Teilfunktionen oder der Umfang
von Tabellen.
Richtigkeit: Merkmale von Software, die sich beziehen auf das Liefern der richtigen oder
vereinbarten Ergebnisse oder Wirkungen. ANMERKUNG: Dazu gehört
beispielsweise die benötigte Genauigkeit von berechneten Werten.
Interoperabilität: Merkmale von Software, die sich auf ihre Eignung beziehen, mit
vorgegebenen Systemen zusammenzuwirken. ANMERKUNG: Interoperabilität
wird anstelle von Kompatibilität benutzt, um mögliche Verwechselungen mit
Austauschbarkeit zu vermeiden.
Ordnungsmäßigkeit: Merkmale von Software, die bewirken, dass die Software
anwendungsspezifische Normen oder Vereinbarungen oder gesetzliche
Bestimmungen und ähnliche Vorschriften erfüllt.
Sicherheit: Merkmale von Software, die sich auf ihre Eignung beziehen, unberechtigten
Zugriff, sowohl versehentlich als auch vorsätzlich, auf Programme und Daten
zu verhindern.
b) Zuverlässigkeit
Reife, Fehlertoleranz, Wiederherstellbarkeit
Reife: Merkmale von Software, die sich auf die Häufigkeit von Versagen durch
Fehlzustände in der Software beziehen.
Fehlertoleranz: Merkmale von Software, die sich auf ihre Eignung beziehen, ein spezifiziertes
Leistungsniveau bei Software‐Fehlern oder Nicht‐Einhaltung ihrer
spezifizierten Schnittstelle zu bewahren. ANMERKUNG: Das spezifizierte
Leistungsniveau schließt Ausfallsicherheit ein.
Wiederherstellbarkeit: Merkmale von Software, die sich beziehen auf die Möglichkeit, bei einem
Versagen ihr Leistungsniveau wiederherzustellen und die direkt betroffenen
Daten wiederzugewinnen, und auf die dafür benötigte Zeit und den
benötigten Aufwand.
c) Benutzbarkeit
Verständlichkeit, Erlernbarkeit, Bedienbarkeit
Verständlichkeit: Merkmale von Software, die sich auf den Aufwand für den Benutzer
beziehen, das Konzept und die Anwendung zu verstehen.
Erlernbarkeit: Merkmale von Software, die sich auf den Aufwand für den Benutzer
beziehen, ihre Anwendung zu erlernen (z.B. Ablaufsteuerung, Eingabe,
Ausgabe)
Bedienbarkeit: Merkmale von Software, die sich auf den Aufwand für den Benutzer bei der
Bedienung und Ablaufsteuerung beziehen.
d) Effizienz
Zeitverhalten, Verbrauchsverhalten
Zeitverhalten: Merkmale von Software, die sich beziehen auf die Antwort‐ und
Verarbeitungszeiten und auf den Durchsatz bei der Ausführung ihrer
Funktionen.
7
Verbrauchsverhalten: Merkmale von Software, die sich darauf beziehen, wie viele Betriebsmittel
bei der Erfüllung ihrer Funktionen benötigt werden und wie lange.
8
e) Änderbarkeit
Analysierbarkeit, Modifizierbarkeit, Stabilität, Prüfbarkeit
Analysierbarkeit: Merkmale von Software, die sich auf den Aufwand beziehen, der notwendig
ist, um Mängel oder Ursachen von Versagen zu diagnostizieren oder um
änderungsbedürftige Teile zu bestimmen.
Modifizierbarkeit: Merkmale von Software, die sich auf den Aufwand beziehen, der zur
Ausführung von Verbesserungen, zur Fehlerbeseitigung oder zur Anpassung
an Umgebungsänderungen notwendig ist.
Stabilität: Merkmale von Software, die sich auf das Risiko unerwarteter Wirkung von
Änderungen beziehen.
Prüfbarkeit: Merkmale von Software, die sich auf den Aufwand beziehen, der zur Prüfung
der geänderten Software notwendig ist ANMERKUNG: Werte dieses
Teilmerkmals können durch die betrachteten Änderungen verändert werden.
f) Übertragbarkeit
Anpassbarkeit, Installierbarkeit, Konformität
Anpassbarkeit: Merkmale von Software, die sich auf die Möglichkeit beziehen, sich an
verschiedene festgelegte Umgebungen anzupassen, wenn nur Schritte
unternommen oder Mittel eingesetzt werden, die für diesen Zweck für die
betrachtete Software vorgesehen sind.
Installierbarkeit: Merkmale von Software, die sich auf den Aufwand beziehen, der zur
Installierung der Software in einer festgelegten Umgebung notwendig ist.
Konformität: Merkmale von Software, die bewirken, dass die Software Normen oder
Vereinbarungen zu Übertragbarkeit erfüllt.
Aufgabe 2
Für (End‐)Benutzer (Fachabteilung) und Administratoren (technische Betreuung) einer
Software haben nicht alle Qualitätsmerkmale aus Aufgabe 1 die gleiche Wichtigkeit,
manche sind sogar „unerheblich“. Versuchen Sie eine entsprechende Zuordnung zu
treffen!
Antwort:
Benutzer (Fachabteilung)
‐ Funktionalität
‐ Benutzbarkeit
‐ Effizienz (Zeitverhalten)
‐ (Änderbarkeit interessiert weniger)
Benutzer (IT)
‐ Effizienz (Speicher, Zeit)
‐ Änderbarkeit
‐ Übertragbarkeit
9
Aufgabe 3
Häufig wird als weiteres Qualitätsmerkmal die Wartbarkeit angeführt.
a) Geben Sie eine Definition des Begriffs!
Antwort:
Def.: Wartbarkeit
Merkmal von Software, drückt den Aufwand aus, um Änderungen an Applikationen aufgrund von
Fehlern oder Wunsch nach neuen Funktionen.
b) Welche der in der Vorlesung gegebenen Qualitätsmerkmale beeinflussen die

Wartbarkeit.
Antwort:
Einfluss auf Wartbarkeit:
Änderbarkeit, Übertragbarkeit
Aufgabe 4
Welche Vorteile bringt die Verwendung eines Vorgehensmodells mit sich?
(Alte Klausurfrage!!!)
Antwort:
Das V‐Modell ist eine abstrakte, umfassende Projektmanagement‐Struktur für die IT‐
Systementwicklung. Sein Name bezieht sich auf die V‐förmige Darstellung der Projektelemente wie
IT‐Systemdefinitionen und Tests, gegliedert nach ihrer groben zeitlichen Position und ihrer Detailtiefe
(siehe Abbildung). In der Regel wird eine neue Variante des V‐Modells aus der jeweils
vorhergehenden Variante entwickelt, sobald ein Verbesserungsbedarf erkannt wird. Im Gegensatz zu
einem klassischen Phasenmodell werden im V‐Modell lediglich Aktivitäten und Ergebnisse definiert
und keine strikte zeitliche Abfolge gefordert. Insbesondere fehlen die typischen Abnahmen, die ein
Phasenende definieren. Dennoch ist es möglich, die Aktivitäten des V‐Modells z. B. auf ein
Wasserfallmodell oder ein Spiralmodell abzubilden.
10
V‐Modelle werden direkt auf das Produkt hin zugeschnitten

Link zum s. V‐Modell
Systematische Anleitung zu erstellen von Software
Vorteile:
‐ Zerlegung der Entwicklung in Teilaufgaben (Teilaufgaben sind sehr Detailliert beschrieben)
=> höhere Transparenz }
=> bessere Planbarkeit } geringeres Risiko
=> einfachere Kalkulation }
‐ Verbesserung der Kommunikation zwischen Projektbeteiligten
‐ Reduzierung von Einarbeitungs‐ und Schulungszeiten
‐ Geringere Abhängigkeit an der Entwicklung beteiligten Personen oder Unternehmen
‐ Verbesserung der Wartbarkeit durch systematische und einheitliche Dokumentation
Aufgabe 5
a) Nennen Sie Vor‐ und Nachteile des Wasserfallmodells. Für welche Entwicklungsaufgaben
ist dieses Modell geeignet?
Antwort:
Vorteile
‐ Einfaches Modell:
‐ Einfache Überwachung des Projektfortschritts
‐ Wenig Zusatzaufwand
‐ Einfach zu erlernen
Nachteile:
‐ hohes Risiko falls Anforderungen nicht konkret sind
‐ bei langer Entwicklungszeit besteht das Risiko, dass die Software nicht mehr den
Anforderungen genügt, wenn sie in Betrieb genommen wird.
‐ Benutzer erhält erst spät einen Eindruck in der Software
‐ Risikofaktoren werden nur unzureichend berücksichtigt
‐ Schwache Einbindung der Benutzer in die Entwicklung
Trotzdem: Verwendung bei
‐ kleineren Projekten
‐ kleineren Anforderungen
b) Nennen Sie Vor‐ und Nachteile der evolutionären Software‐Entwicklung? Für welche
Entwicklungsaufgaben ist dieses Modell geeignet?
Recherchieren Sie im Internet!
Antwort:
Evolutionäre Software‐Entwicklung
Vorteile:
‐ starke Einbindung der Benutzer
‐‐Benutzer stehen in kürzeren Zeitabständen größer werdende einsatzfähige Teile
des Gesamtsystems zur Verfügung
‐ gewonnene Erfahrungen der Benutzer mit dem Systemtreiber fließen sofort in die
Entwicklung mit ein
‐ schnelles Feedback
‐ einsetzbar auch bei unklaren Anforderungen
11
Nachteile:
‐ schwierige Kontrolle des Projektfortschritts
‐ Änderungen können unter Umständen die Gesamtarchitektur betreffen
Wann?
‐ Unklare Anforderungen
‐ schnelle Produktumsetzung von Teilsystemen
‐ Benutzeroberfläche,…
Aufgabe 6
In welchen Phasen der Entwicklung sollten die Qualitätsmerkmale der Software festgelegt
werden?
Entwurf (Design)
Aufgabe 7
In einem Unternehmen soll für die Vertriebsabteilung eine neue Software zur Bearbeitung
der Kundenanfragen, zur Angebotserstellung, zur Auftragserfassung und zur
Rechnungsstellung entwickelt werden. In welchen Phasen der Softwareentwicklung
müssen Mitarbeiter der Fachabteilung aktiv mitarbeiten?
Antwort:
Analyse, beim Test (Akzeptanz, Abnahme)
12
3. Analyse und Definition

Ziel Ermittlung, Prüfung und Dokumentation der Anforderung als Grundlage für die Entwicklung der
Software
Also: Was soll entwickelt werden?
Begriffe:
Def: Anforderung:
Bedingung oder Fähigkeit, die eine Software erfüllen, oder besitzen um
beispielsweise einen Vertrag, eine Norm, usw. zu erfüllen.
D.h. Anforderungen legen die quantitativen und qualitativen Eigenschaften einer Software
fest
Anforderungsspezifikation: Zusammenstellung aller Anforderungen an eine Software
Synonyme: Anforderungsdokument
Software Requirement
Spezifikation
Häufig werden die Begriffe Lastenheft bzw. Pflichtenheft verwendet
Lastenheft:
‐ Gesamtheit der Forderungen des Auftraggebers an Lieferungen und Leistungen des
Auftragnehmers
‐ Grundlage für die Angebotserstellung
‐ in der Regel vom Auftraggeber erstellt
‐ Vorstufe des Pflichtenheftes; Anforderungen sind i.d.R. nur grob beschrieben
Pflichtenheft:
‐ vom Entwickler (Systemanalyst) in Zusammenarbeit mit dem Auftraggeber auf Grundlage
des Lastenhefts erstellt
‐ zu erfüllende Leistungen (Anforderungen) sind klar und unmissverständlich beschrieben
‐ Vertragscharakter
Requirements Engineering:
Systematische, disziplinierte, quantitativ erfassbare Vorgehensweise beim Spezifizieren
(Analysieren, Erfassen, Beschreiben, Prüfen) von Anforderungen an eine Software
Also: Verstehen und beschreiben, was der Auftraggeber will!
Klassifizieren von Anforderungen:

1. Klassifikation in funktionale und nicht funktionale Anforderungen
Funktionale Anforderungen spezifizieren:

‐ Daten (Struktur, Verwendung, Erzeugung, Speicherung, usw.)
‐ Funktion (Eingabe, Verarbeitung, Ausgabe von Daten)
‐ dynamisches Verhalten (Zusammenspiel von Funktionen, usw.)
‐ Benutzeroberfläche
Nicht funktionale Anforderungen spezifizieren:

‐ Art und Weise in der Funktionalität erbracht werden soll
‐ Beispiele: Antwortzeiten, Eigenschaften der Hardware, Liefertermin,
Programmiersprache, usw. )
13
2. Klassifizieren nach Lebensdauer

‐ dauerhafte Anforderung (geringe Änderungswahrscheinlichkeit während der Entwicklung
und Betrieb der Software)
‐ flüchtige Anforderung (Daten die zukünftig geändert werden könnten, nicht in den
Quellcode mit einbeziehen)
Priorisierung von Anforderungen
‐ Muss Anforderung (unverzichtbare Anforderungen)
‐ Soll‐ Anforderung (soll erfüllt werden, bei zu hohen Kosten verzichtbar)
‐ Wunsch‐Anforderungen ("Nice to have", nur zu erfüllen, wenn dies mit vertretbaren Kosten
möglich ist)
Darstellung von Anforderungen
Oft wird unterschieden zwischen Definition und Spezifikation von Anforderungen
Definition von Anforderungen
‐ Kundenorientierte Beschreibung einer Anforderung (Text)
Spezifikation von Anforderungen:
‐ Präzise und detaillierte Beschreibung der Anforderungen für den Entwickler
‐ Grundlage für die weitere Systementwicklung
Techniken
‐ Textform (strukturierte Sprache (pseudo Code))
‐ grafische Beschreibungen
‐ mathematische (formale) Spezifikation
Validierung von Anforderungen

Erbringung des Nachweises, dass die Anforderungen das System definieren, das der Kunde will.
‐ Widerspruchsfrei
‐ Adäquatheit
‐ Verständlichkeit
‐ Vollständigkeit
‐ Eindeutigkeit
‐ Prüfbarkeit
‐ Verfolgbarkeit
‐ Anpassbarkeit
14
2. Übung
Aufgabe 1
Eine textuelle Spezifikation von Anforderungen in natürlicher Sprache hat den großen
Vorteil, dass sie leicht erstellbar und lesbar ist. Sie hat jedoch den Nachteil, dass in der
Regel viele Unklarheiten, Auslassungen, Mehrdeutigkeiten und Widersprüche enthalten
sind. Gegeben ist nun der folgende Ausschnitt aus der Spezifikation der Steuerung eines
Getränkeautomaten:
1Der Bediener drückt eine Wahltaste und bezahlt den geforderten Betrag. Sobald die
2Summe der eingeworfenen Münzen den geforderten Betrag übersteigt, wird das Getränk
3zubereitet und ausgegeben. Ferner wird das Wechselgeld berechnet und ausgegeben.
4Der Bedienvorgang endet, wenn das Getränk entnommen wird und wenn die Bedienung
5für länger als 45s unterbrochen wird. Mit einer Annullier‐Taste kann der Bedienvorgang
6jederzeit abgebrochen werden. Bereits eingeworfenes Geld wird beim Drücken der
7Annulliertaste zurückgegeben. Nach dem Drücken einer Wahltaste kann entweder bezahlt
8oder eine andere Wahltaste gedrückt werden. Die zuletzt getätigte Auswahl gilt.
Untersuchen Sie die Spezifikation auf Unklarheiten, Mehrdeutigkeiten, Fehler und
Widersprüche!
Antwort:
Zeile 2: Fehler: Was ist bei Betragsgleichheit?
Zeile 1: Unklarheit: Reihenfolge von Auswahl und Bezahlung. Wiederspruch zu Zeile 7/8
Zeile 5/6: Unklarheit: Kann während der Getränkeausgabe abgebrochen werden?
Zeile 4: Mehrdeutigkeit: Ist "und" oder "oder" gemeint?
Allgemein: Unvollständigkeit: Welche Münzen werden akzeptiert?
Was passiert mit fehlerhaften Münzen?
Aufgabe 2
Formulieren Sie die folgenden Anforderungen so um, dass sie objektiv zu überprüfen sind.
a) Das Softwaresystem sollte auch bei maximaler Last mit ausreichend Performanz
arbeiten.
Antwort:
Auch bei maximaler Last müssen die Antwortzeiten des Systems bei Dialogverarbeitung unter 2
Sekunden liegen.
b) Wenn das System ausfällt, sollte nur eine minimale Menge an Information verloren
gehen.
Antwort:
Wenn das System ausfällt, dürfen nur die Informationen verloren gehen, die gerade Bearbeitet
worden sind. (Nichtabgeschlossene Transaktionen, z.B. laufende Bestellanlegung)
c) Der benutzte Software‐Entwicklungsprozess muss sicherstellen, dass alle verlangten
Reviews ausgeführt worden sind.
Antwort: Die Softwareentwicklung muss gemäß Standard … erfolgen. Die dort vorgesehenen Reviews
müssen entsprechend der im Standard formulierten Vorgaben ausgeführt und protokolliert werden.
d) Die Software muss so entwickelt werden, dass sie auch von unerfahrenen Benutzern
benutzt werden kann.
Antwort: Die Software muss so entwickelt werden, dass ein Benutzer mit folgenden Vorkenntnissen;
… die folgenden Geschäftsvorfälle …. nach einer 2‐stündigen Schulung vom System bearbeiten kann.
15
Aufgabe 3
Ian Sommerville hat in seinem Standardwerk zum Software Engineering nicht funktionale
Anforderungen wie folgt klassifiziert:
Formulieren Sie nicht funktionale Beispielanforderungen zu den Klassen Product

Requirements und External Requirements bezüglich der an der Fachhochschule genutzten
Lernplattform studip!
Antwort
Benutzbarkeit: Nach einer ½‐stündigen Schulung müssen die Studierenden in der Lage sein, den
Download/Upload von Dateien durchzuführen, Kurse auszuwählen und sich zuzuordnen, usw.
Performance: Die Antwortzeiten müssen bei Zugriff über das Intranet unter 2 Sekunden liegen.
Speicher: Speicherbedarf für einen Kurs wird standardmäßig auf 40MB begrenzt.
Zuverlässigkeit: Zwischen 8:00 und 22:00 werden 95% der Zugriffe auf das System (erfolgreich)
bearbeitet. Systemausfälle müssen binnen 12 Stunden behoben werden können.
Portabilität/ Interoperabilität: Export der Ergebnisse aus Onlinetests nach MS‐Excel zur weiteren
Auswertung muss unterstützt werden. Stud‐ip muss sowohl in einer Windows‐ als auch in einer
Linux‐Umgebung betrieben werden können.
Datenschutz: Dem Dozenten darf es nicht möglich sein zu ermitteln, welche Studenten auf Dateien
zugegriffen haben.
Aufgabe 4
Geben Sie Maße für folgende Softwareeigenschaften an: Geschwindigkeit, Speicher,
Benutzerfreundlichkeit, Zuverlässigkeit, Übertragbarkeit und Robustheit
Geschwindigkeit: Antwortzeit in Sekunden bei Dialogverarbeitung
Anzahl Transaktionen pro Stunde
Zeit für Neuaufbau des Bildschirms (Refresh)
Speicher: MB, GB
Anzahl Speicherchips
Benutzerfreundlichkeit: Schulungsaufwand in Tagen pro Benutzer
Anzahl der Einträge in der Online‐Hilfe
Erlernbarkeit
Zuverlässigkeit: Durchschnittliche Ausfälle
Verfügbarkeit in %
Portabilität: Anzahl der plattformabhängigen Programmanweisungen (Hardware,
Software)
Robustheit: Wahrscheinlichkeit, dass im Fehlerfall Daten zerstört werden.
Zeit, die benötigt wird, das System nach einem Ausfall neu zu starten
16
Besprechung des Pflichtenheftes

Hervorgehoben wurde in diesem Fall die Ist‐Aufnahme und die ist Analyse; Fachliche Anforderungen
insbesondere 6.6 und 6.7
4. Grundlegende Techniken zu Beschreibung von Anforderungen
Funktionsbaum
Funktion allgemein: Tätigkeit oder eine klar umrissene Aufgabe in einem größerem
Zusammenhang
In unserem Kontext:
Wichtige Eigenschaften;
Funktion ermittelt aus Eingabedaten nach bestimmten Vorgaben
Ausgabedaten
EingabeÆFunktionÆAusgaben
Verändert den Inhalt oder Struktur von Informationen
Funktionelle Hierarchie:
Gliederung einer allgemeinen Funktion in spezielle Teilfunktionen
und Anordnung der Teilfunktionen nach bestimmten Kriterien.
Funktionale Hierarchie kann als Funktionsbaum dargestellt werden.
Vaterfunktion von B u. C A Kindfunktion von A
B C
Interpretation:
a) A besteht aus B und C
b) A ruft B und C auf
Beispiel:
Einkaufsabwicklung
Anfragebearbeitung Angebotsbearbeitung Bestellbearbeitung
Anfrage anlegen Angebot anlegen Bestellung anlegen
Anfrage ändern Angebot ändern Bestellung ändern
Anfrage löschen Angebot löschen Bestellung versenden
Anfrage stornieren Angebot vergleichen Bestellung löschen
Anfrage versenden Bestellung stornieren
Bestellung überwachen
17
Regeln:
a) Funktionen auf einer Hierarchieebene sollten das gleiche Abstraktionsniveau haben
b) Fachlich zusammenhängende Funktionen unter einer Vaterfunktion zusammengefasst werden.
Data Dictionary
Datenverzeichnis, das Informationen über Daten, ihre Beziehungen, Struktur und Verwendung
enthält.
Wird während der Analyse, Design, Implementierung und Test zum Nachschlagen und zur
Konsolidierung verwendet.
Es gibt unterschiedliche Notationen, z.B. BNF‐ähnliche Notationen.
Beispiel: (De Marco) "()optional"

Kundendatei = {Kundeneintrag}
Kundeneintrag = Ku.Nr. + Name + Adresse + (Geburtsdatum) + (Funktion) + Umsatz
Name = Anrede + (Titel) + Vorname + Nachname
Adresse = [Straße + Hausnummer| Postfach‐Nr. ] + (Länderkennzeichen) + PLZ + Ort
"[]" Auswahl‐
möglichkeite
+ (Telefonnummer) + (Faxnummer)
"Zusammengesetzte" Daten (z.B. Kundeneintrag) werden hier als Datenstrukturen, die anderen als
Datenelemente bezeichnet (z.B. PLZ).
Entity ‐ Realationship‐ Modell

Zweck: Analyse und graphische Beschreibung von Daten, ihrer Struktur und ihrer Beziehungen.
Wichtigste Elemente:
‐ Entitäten sind identifizierbare Objekte aus der realen oder fiktiven Welt, die durch
Anforderungen an das Softwaresystem bestimmt sind.
Entitäten gleichen Typs werden unter Entitätssystem zusammengefasst.
‐ Attribute / Attributwerte bezeichnen die Eigenschaften der Entitäten.
‐ Beziehungen zwischen Entitäten
Beispiel:
Pers. Nr. Veranst. Nr.

Attribute
Name Name
Vorname SWS
1+n 0‐m
Dozent hält Veranstaltung
1+n Kardinalität 1+n
Entit‐
tätstypen
Gehört zu
bearbeit
1+n 1+1
Beziehungstypen
Themengebiet
Gebietsnummer
Thema
18
Beschreibung von Abläufen / Algorithmen

a) Programmablaufplan
b) Strukturgramme
c) Pseudo‐Code (strukturierte Sprache)
19
3. Übung
Aufgabe 1
Die Gewinnung und Beschreibung von Anforderungen ist ein schwieriger und aufwendiger
Prozess. Nennen Sie typische Probleme die bei der Gewinnung von Anforderungen
auftreten!
‐ Kunden haben Schwierigkeiten ihre Vorstellungen und Wünsche zu formulieren, bzw. beschreiben
eine ihnen bekannte Lösung
‐ Geld schränkt die Möglichkeiten ein => Konflikte mit den Endbenutzern
‐ Begriffsdiskrepanzen (unterschiedliche Begriffe werden unterschiedlich vom Endwickler und
Kunde/Endbenutzer interpretiert.
‐ Unterschiedliche Vertreter des Kunden haben unterschiedliche Vorstellungen, über das zu
spezifizierende Produkt => Konflikte
‐…
Aufgabe 2
Das V‐Modell XT ist ein Vorgehensmodell und als Entwicklungsstandard für IT‐Systeme
des Bundes für die Planung und Durchführung von IT Projekten verbindlich
vorgeschrieben.
a) Wie werden im V‐Modell XT Lasten‐ und Pflichtenheft unterschieden?
Lastenheft:
Verantwortlich: Anforderungsanalytiker (Auftraggeber)
Bedeutung: ‐ Verbindlich gestellte Anforderungen an das Gesamtsystem, die das System
vollständig und konsistent beschreiben
Funktionale Anforderung
Nichtfunktionale Anforderung
Skizze des Gesamtsystementwurfes
Lieferungsbedingungen
Abnahmekriterien
‐ Grundlage für Ausschreibung und Vertragsgestaltung, Bestand des Vertrags
zwischen Antragnehmer und Antraggeber (Anhang 1: Anforderungen an das
zu erstellenden Systems)
Inhalte: 1. Ausgangssituation und Zielsetzung
2. Funktionale Anforderung
3. Nichtfunktionale Anforderung
4. Skizze des Lebenszyklus
5. Risikoakzeptanz
6. Lieferumfang
7.Abnahmekriterium
Pflichtenheft:
Verantwortlich: Anforderungsanalytiker (Auftragsnehmer)
Bedeutung: ‐ Pendant zum Lastenheft
‐ Wird vom Auftragnehmer in Zusammenarbeit mit dem Auftraggeber
erstellt
‐ Funktionale und Nichtfunktionale Anforderungen an das zu entwickelnde
System
‐ Anforderungen werden aus dem Lastenheft entnommen, weiter
dokumentiert, detailliert, ergänzt,…
20
Inhalte: 1. Ausgangssituation und Zielsetzung

2. Funktionale Anforderungen Ist‐AnalyseÆSollkonzept
3. Nichtfunktionale Anforderungen
4.Risikoakzeptanz
5. Lebenszyklusanalyse und Gesamtarchitektur
6. Schnittstellenübersicht
7. Lieferumfang
8. Abnahmekriterien
9. Anforderungsverfolgung zu den Anforderungen im Lastenheft
10. Anforderungsverfolgung
Beispiele: Lastenheft, Pflichtenheft Æ Helmut Balzert: Software‐Technik Band 1
b) Das V‐Modell definiert Rollen, für die an einem Projekt beteiligten Personen und legt
für jede Rolle fest, für welche Produkte und Aktivitäten eine Rolle verantwortlich ist.
Bestimmen Sie die Rollen, die für die Erstellung des Lastenhefts bzw. für die
Erstellung des Pflichtenhefts verantwortlich sind.
Aufgabe 3
Am Umwelt‐Campus wurde ein neues E‐Mail‐System (https://webmail.umwelt‐campus.de)

eingeführt. Stellen Sie die Funktionen, die dem Adressbuch‐Menü zugeordnet sind als
Funktionsbaum dar.
Adressbuch bearbeiten
Adressen hinzufügen Erweiterte Suche CSV‐Import
Speichern Suchen Durchsuchen
Übernehmen Abbruch Import
Abbruch
Löschen
Aufgabe 4
Für die Personalabteilung eines mittelständischen Unternehmens soll eine neue Software
für die Personalabteilung entwickelt werden. Eine wichtige Komponente in diesem System
ist die Verwaltung der Urlaubsansprüche der einzelnen Mitarbeiter. Bei der Aufnahme der
Anforderungen verweisen sie die Mitarbeiter auf den folgenden Auszug aus einem
Bundes‐Tarifvertrag:
Der Mindestanspruch beträgt auf Basis einer Fünf‐Tage‐Woche:
1. für Arbeitnehmerinnen vor Vollendung des 30. Lebensjahres 26 Werktage
2. für Arbeitnehmerinnen nach Vollendung des 30. Lebensjahres 27 Werktage
Der Mindestanspruch erhöht sich jedes Jahr der Betriebszugehörigkeit mit vollem
Urlaubsanspruch um einen Urlaubstag.
1. für Arbeitnehmerinnen vor Vollendung des 30. Lebensjahres bis zu höchstens
29 Werktagen
2. für Arbeitnehmerinnen nach Vollendung des 30. Lebensjahres bis zu
höchstens 31 Werktagen
Beschreiben Sie die Bestimmung des Urlaubanspruchs in Abhängigkeit von Alter und
Anzahl der Jahre der Betriebszugehörigkeit eines Mitarbeiters als Programmablaufplan
und Struktogramm.
21
Aufgabe 4
Programmablaufplan (PAP)
Start
Bestimme
Alter (A)
Bestimme Jahre vor

Betriebszugehörigkei
t (B)
nein ja
A >= 30
Urlaubsanspruch (U)
nein ja
A >= 50
= 26 + B
nein C
U = 29 U = 27 + B
U <= 29
ja
U = 30
U <= 30
A
ja
A B C
U = 28 + B
U <= 33
ja
U = 29
U ausgeben
22
End
Aufgabe 5
Der Leiter der Personalabteilung aus Aufgabe 4 berichtet erläutert Ihnen, dass auch
langfristig der die Berechnung des Urlaubanspruchs eines Mitarbeiters in Abhängigkeit
von Alter und Dauer der Betriebszugehörigkeit bestimmt werden wird. Eine Änderung der
Altersstufen, Einfluss der Dauer der Betriebszugehörigkeit und maximaler Urlaubsanspruch
können sich jedoch ändern. Wie würden Sie nach dieser Aussage die Berechnung des
Urlaubsanspruches spezifizieren?
Vorschlag: Anzahl Altersstufen bleibt gleich, 2 Altersstufen werden parametrisiert; AS(1)=30;

AS(2)=50; Mindesturlaubsanspruch MU(1)=26; MU(2)=27; MU(3)=29; Maximaler Urlaubsanspruch
MAXU(1)=29; MAXU(2)=31; MAXU(3)=33;
(Struktogramm!!!)
Bestimmtes Alter (A)
Bestimme Jahre der Betriebszugehörigkeit (B)
A >= AS(1)
Nein Ja
U= MU(1) + B A >= AS(2)
Nein ja
U <= MU(B) U= MU(2) + B U = MU(3) + B
Ja nein
U<=MAXU(2) U<=MAX(3)
/ U=MAXU Ja nein Ja nein
/ U=MAXU(2) / U=MAXU(3)
U ausgeben
Strukted.zip
Altersstufen MU MAX U
Nr. Wert Nr. Tage Nr. Tage
1 30 1 26 1 29
2 50 2 27 2 31
3 28 3 33
23
5. Objektorientierte Analyse und Design mit UML im Überblick

Allgemeine Bemerkungen
Probleme in der SW‐Entwicklung
‐ Falsches Verständnis der Bedürfnisse der Benutzer
‐ Unfähig mit wechselnden Anforderungen
‐ Module passen nicht zusammen
‐ spätes Erkennen von Fehlern
‐ Teammitglieder arbeiten unterschiedlich, keine Standards
Ein Mittel zu Lösung der Probleme: (Visuelle)Modellierung
Problemstellung aus der Log. Ebene Modelle, die eine Physische Ebene
realen oder fiktiven Welt Software beschreiben Implementierung
Zentrale Fragen:
‐ Welche Modelle sollen erstellt werden?
‐ In welcher Notation sollen die Modelle beschrieben werden?
Modell:
Modell= vereinfachtes Abbild der Realität
Es gibt unterschiedliche Modelle:
‐ Strukturmodelle beschreiben den Aufbau eines Systems
‐ Verhaltensmodelle: beschreiben die dynamischen Aspekte eines Systems
Warum?
‐ besseres Verständnis vom zu entwickelndem System
‐ komplexe Systeme sind ohne Modelle nicht mehr zu verstehen, zu überschauen,…
‐…
Grundlegende Eigenschaften
‐ Entscheidung welche Modelle ausgewählt werden, hat einen großen Einfluss auf die
Entwicklung
‐ Modelle können in unterschiedliche Detailgraden erstellt werden
‐ Kein einzelnes Modell ist ausreichend
‐….
Einem komplexen System nähert man sich am besten mit einer kleine Anzahl unabhängiger Modelle
unter verschiedenen Sichten.
Einführung UML
Objektorientierung ist seit den 90er Jahren das zentrale Programmierparadigma
Was sind Objekte?
‐ Einheit, die Eigenschaften von Prozeduren und Daten kombinieren
Objekte werden durch ihre Eigenschaften und ihr Verhalten beschrieben.
‐ Weiterentwicklung der abstrakten Datentypen
Bsp.
Gegenstände aus der realen Objekte bzw. Klassen

Welt
Grundkonzepte Details Î Prog 3

‐ Objekte
‐ Klasse
‐ Attribute
‐ Operationen (Methoden, Services)
‐ Beziehungen zwischen Klassen, z.B. Vererbung
‐ Polymorphie (Vielgestaltigkeit)
24
UML = Unified Modeling Language

‐ standardisierte graphische Modellierungssprache zu Visualisierung, Spezifizierung,
Konstruktion und Dokumentation von Softwareintensiven Systemen
‐ prozessunabhängig
‐ einsetzbar in vielen Anwendungsdomänen
‐ De facto Standard für die objektorientierte Softwareentwicklung
25
4. Übung
Aufgabe 1
Recherchieren Sie und definieren Sie die folgenden Begriffe:
a) Anwendungsdomäne
Unter einer Anwendungsdomäne, häufig auch verkürzt Domäne, versteht man in der Informatik und
insbesondere in der Softwaretechnik ein abgrenzbares Problemfeld des täglichen Lebens oder ‐
etwas spezieller ‐ einen bestimmten Einsatzbereich für Computersysteme oder Software.
Anwendungsdomänen stellen typischerweise sehr spezielle Anforderungen an ein technisches
System, welches zur Simulation oder auch Bewältigung der domänenspezifischen Aufgaben und
Probleme eingesetzt werden soll. Diese Anforderungen fließen insbesondere im Rahmen der
Anforderungsanalyse, die einer Systementwicklung vorausgeht, und während des Entwurfs des
Systems in den Entwicklungsprozess ein und bestimmen maßgeblich die Modellbildung oder auch
Modellierung, die der späteren Realisierung zu Grunde liegt. Der Begriff wird häufig dann eingesetzt,
wenn es für den betreffenden Einsatzbereich eine Vielzahl ähnlicher Systeme gibt, die allesamt die
Anforderungen der Domäne umsetzen müssen. Anwendungsdomänen eignen sich daher gut für die
Wiederverwendung von Architekturen und Komponenten eines Systems.
b) Stakeholder
Die Entwicklung eines Systems (z. B. eines Computersystems) hat das Ziel, die Bedürfnisse mehrerer
Personen, Gruppen, Institutionen oder Dokumente und Regelwerke (z. B. Gesetzestexte) zu
befriedigen, wobei die Bedürfnisse und Ansprüche sehr unterschiedlich, auch gegenläufig und
widersprüchlich, sein können. All diese Personen und Institutionen bezeichnen wir als Stakeholder.
Stakeholder dienen der Abstraktion, indem ein Stakeholder jeweils die Zusammenfassung aller
Personen mit gleicher Interessenlage und gleicher Sicht auf das System repräsentiert.
Die Definition des Begriffes Stakeholder stimmt hier im Wesentlichen mit dem Begriff des
Projektbeteiligten der DIN 69905 überein.
In unserem Bereich: Inhaber der Firma, Benutzer, Programmierer,
Aufgabe 2
Lesen Sie in der Dokumentation zum V‐Modell XT die Beschreibung Teilaktivität Erfassen
und Beschreiben der funktionalen Anforderungen in Textform, die Teil der Aktivität
Anforderungen und Analysen _ Anforderungen festlegen _ Funktionale Anforderungen
erstellen ist.
a) In einem ersten Schritt ist bei Ausführung der Teilaktivität das Problemfeld
aufzubereiten und die Erfassung der Anforderungen organisatorisch und technisch
vorzubereiten. Welche Vorschläge werden hierzu gemacht?
‐ Analyse von Systemdokumenten und Marktstudien,
‐ Ermitteln von speziellem Wissen im Geschäftsbereich,
Erfassung der Anforderung organisatorische und technischen Vorbereitungen
‐ Erstellen von Fragebögen (Testen, Vorhersehen)
Information der Beteiligten über die einzusehenden Hilfsmittel
Schablone textuellen Beschreibungen oder Anforderungen
Schema zur Kurzbeschreibung einer Anforderung
Anzuwendende Qualitäts‐Kriterien für Anforderungen (DIN ISO 9126)
Stilratgeber für die Formulierung von Anforderungen
‐ Vorbereiten und Testen von Fragebögen,
26
b) Welche Techniken zur Ermittlung der Anforderungen werden vorgeschlagen?

Kreativitätstechniken eignen sich dazu, erste Ideen zu sammeln und eine erste Übersicht über das zu
entwickelnde System zu schaffen. Beispiele sind Brainstorming, Metaplan‐Technik, Mind‐Mapping,
Durchführung strukturierter Workshops oder Problemlösungssitzungen.
Beobachtungstechniken eignen sich dazu, sowohl Anforderungen auf sehr detailliertem Niveau als
auch unterbewusste Anforderungen zu ermitteln. Beispiele hierfür sind Feldbeobachtung und
Apprenticing ("in die Lehre gehen").
Befragungstechniken mit Fragebogen, Interviews, eigenen Notizen der Befragten und On‐Site‐
Customer sind zur Ermittlung von Anforderungen beliebiger Detaillierungsgrade geeignet.
Vergangenheitsorientierte Techniken sind geeignet, um bestehende Lösungen in ein neues System
zu integrieren. Es wird die Möglichkeit geschaffen, Erfahrungen aus bereits erfolgreich
abgeschlossenen Systementwicklungen wieder zu verwenden.
Aufgabe 3
Für die textuelle, einheitliche Spezifikation von funktionalen Anforderungen kann man
Schablonen verwenden, die bei Funktionen nach Ian Sommerville folgende Elemente
enthalten sollten:
Funktion Name der Funktion
Kurzbeschreibung Kurze informelle Beschreibung der Funktion
Eingaben Beschreibung der Eingaben, die verarbeitet werden
Quelle Beschreibung der Herkunft der Eingaben (z.B. Benutzereingaben)
Ausgaben Beschreibung der Ausgaben, die erzeugt werden
Ziel Beschreibung, wo die Ausgaben hingeschrieben werden.
Verwendet Beschreibung , was verwendet wird, z.B. Daten, die vorhanden

sein müssen.
Vorbedingungen Beschreibung der Bedingungen, die erfüllt sein müssen, damit die
Funktion ausgeführt werden kann.
Nachbedingungen Beschreibung der Bedingungen, die nach Ausführung der
Funktion erfüllt sind.
Seiteneffekte Beschreibung der Seiteneffekte der Funktion.
Funktion: Urlaubsbestimmung
Kurzbeschreibung: langfristige Berechnung des Urlaubanspruchs eines Mitarbeiters in
Abhängigkeit von Alter und Dauer der Betriebszugehörigkeit.
Eingaben: Alter, Betriebszugehörigkeit, Min. Urlaubsanspruch, Max. Urlaubsanspruch,
Geburtsdatum, Eintrittsdatum, Aktuelles Datum, Grenzen für Altersklassen
Quelle: Datenbanken,
Geburtsdatum: Benutzereingabe
Eintrittsdatum: Benutzereingabe
Aktuelles Datum: Benutzereingabe
Min, Max, Klassengrenzen DB/Conf‐file
Ausgaben: Urlaubsanspruch in Tagen
Ziel: Formularfeld
Verwendet: DB/Conf‐file mit Min, Max Klassengrenze
Vorbedingungen: Geb. Dat<EintrittsDatum
Eintrittsdatum<aktuelles Datum
Nachbedingungen: Urlaubstage einer Arbeitnehmerin vor/nach 30. Lebensjahr
Urlaubstage einer Arbeitnehmerin nach Vollendung des 50. Lebensjahrs
Seiteneffekte: (könnte es dann geben, wenn Daten in der Datenbank geändert werden)
27
Aufgabe 4
Eine grundlegende Technik zur Dokumentation von Anforderungen sind
Entscheidungstabellen. Mit ihnen können vorzunehmende Aktionen oder Tätigkeiten, die
von einer oder mehreren Bedingungen abhängen, systematisch und übersichtlich
definiert werden. Eine Entscheidungstabelle ist wie folgt aufgebaut:
Name der ET R1 R2 R3 R R8
B1 F T F T
2
B F F T T
B3 F F F T
A1 X X
A2 X
A3 X
A4 X X
B1, B2, und B3 sind Bedingungen. A1, A2, A3, A4 sind Aktionen. R1, R2, R3, ..., R8 sind
Regeln, die angeben, wann die Bedingungen erfüllt sind. Die Regel R1 drückt aus, dass
wenn keine Bedingung erfüllt ist, auch keine Aktion ausgeführt wird. Die Regel R2 drückt
aus, dass wenn Bedingung B1 erfüllt ist und B2 und B3 nicht erfüllt sind, die Aktionen A1
und A2 ausgeführt werden. Die weiteren Regeln sind analog zu interpretieren. Beim
Erstellen einer Entscheidungstabelle, müssen nur die Regeln aufgeführt werden, die
sinnvoll sind.
Erstellen Sie Entscheidungstabellen für folgende Szenarien:
a) Sie arbeiten als Systemanalyst in einem Softwareprojekt. Ziel ist es, ein
Anwendungssystem für die Vertriebsabteilung eines mittelständischen Unternehmens
zu entwickeln. Bei der Aufnahme der Anforderungen erläutert Ihnen die Mitarbeiterin
der Vertriebsabteilung die Bearbeitung eines Kundenauftrags:
Wenn der bestellte Artikel nicht lieferbar ist, wird der Artikel nachbestellt. Kunden,
deren Zahlungsverhalten in der Vergangenheit schlecht war, erhalten in diesem Fall
zusätzlich einen schriftlichen Zwischenbescheid. Die anderen Kunden informieren wir
telefonisch über die Lieferverzögerung. Außerdem liefern wir nur an Kunden mit
einwandfreien Zahlungsverhalten per Rechnung. An die anderen liefern wir per
Nachnahme.
Erstellen Sie eine entsprechende Entscheidungstabelle.
b) Sie arbeiten als Systemanalyst in einem Softwareprojekt. Ziel ist es, ein
Anwendungssystem für die Personalabteilung eines mittelständischen Unternehmens
zu entwickeln. Bei der Aufnahme der Anforderungen erläutert Ihnen die Mitarbeiterin
die Prämienauszahlung an Mitarbeiter des Unternehmens:
Mitarbeiter die 10 Jahre im Unternehmen sind, erhalten ein Zusatzgehalt. Mitarbeiter,
die 25 Jahre im Unternehmen sind, erhalten zwei Zusatzgehälter. Alle anderen
erhalten kein Zusatzgehalt. Die Prämie wird immer in dem Monat ausgezahlt, in dem
der Mitarbeiter in das Unternehmen eingetreten ist.
Erstellen Sie eine entsprechende Entscheidungstabelle!
28
a)
R1 R2 R3 R4
Artikel lieferbar F F R R
Kunden, deren Zahlungsverhalten in der Vergangenheit schlecht war R F R F
Nachbestellung X X
Schriftlicher Bescheid X
Telefonischer Bescheid X
Per Rechnung X
Per Nachnahme X
b)
R1 R2 R3 R4
Kalender‐Eintrittsjahre>10 ? F T T
Kalender‐Eintrittsjahre<25 ? F F T
Kalender‐Eintrittsjahre=Eintrittsmonat F T T T
Keins X X
Eins X
Zwei X
29
UML = Unified Modeling Language
Metamodel
Festlegung der Syntax und Semantik der Modelle
1. Bestandteile:
a) "Dinge"
‐ strukturelle Dinge (Klassen, Komponenten, Anwendungsfälle,…)
‐ Verhaltensdinge (Aktivitäten,…)
‐ Anwendungsdinge
‐ Gruppierungsdinge (Pakete)
b) Beziehungen (Assoziationen, Generalisierungsbeziehungen,…)
c) Diagramme
2. Regeln
3. Mechanismen z.B. für Erweiterungen
Modell: Dinge + Beziehungen + Diagramme
Diagramm: ‐ graphische Darstellung der Modellierungselemente, meistens als Graph
‐ stellt oft nur eine Auswahl der Elemente dar, die ein System (bzw. Modell)
ausmachen
In UML gibt es verschiedene Modelle, die unterschiedliche Sichten auf den jeweiligen Sachverhalt
ermöglichen.
Modelle können sich vom Detaillierungsgrad unterscheiden.
In UML,
‐ Strukturelle Modelle:
Klassendiagramm, Objektdiagramm, Paketdiagramm, Komponentendiagramm,
Verteilungsdiagramm,…
‐ Verhaltensmodelle
Use‐Case‐Diagramm, Aktivitätsdiagramm, Zustandsdiagramm,
Interaktionsdiagramme (z.B. Sequenzdiagramme),…
Sichten: ‐ Sicht umfasst eine Teilmenge der Bestandteile eines Modells
‐ Sichten werden beeinflusst durch Lebenszyklus und Rollen
Tools: ‐ Unterstützen bei der Erstellung von UML‐Modellen
Beispiele: Rational Software Architekt (Modeler) (von IBM)
Visual Paradigm
Bemerkungen:
‐ In UML ist vieles optional
‐ UML‐Modelle sind selten vollständig
‐ In UML gibt es unterschiedliche Darstellungsformen für Elemente
30
6 Anwendungsfallmodelle
Motivation
Zentrale Frage bei Beginn der Systementwicklung
Was soll das zu entwickelnde System leisten?
Nutzer beschreibt das externe Verhalten eines Systems aus seiner Sicht. D.h. er beschreibt
die Aufgaben die er mit dem System bearbeiten möchte, und wie er sich die Interaktionen
mit dem System vorstellt.
=> Beschreibung als Anwendungsfallmodell
Ziele:
‐ Funktionalität eines Systems oder einer Komponente übersichtlich darstellen
‐ Beschreibung der Systemfunktionalität auf einem hohen Abstraktionsniveau
‐ Zerlegen des Systems aus Nutzersicht in logisch zusammenhängende Einheiten
Phase: Anforderungsanalyse
Englisch: Anwendungsfallmodell = UseCase‐Modell
Notationselemente:
System, Akteur, Anwendungsfall, Beziehungen
System:
Betrachtungs‐ bzw. Entwicklungsgegenstand
‐ Einheit, die das Verhalten, welches durch die Anwendungsfälle beschrieben wird, realisiert
und anbietet.
‐ Also: Software, die bestimmte Funktionen für den Akteur, z.B. Nutzer, ausführt.
‐ System kann in Subsysteme untergliedert werden, die logisch zusammenhängende
Anwendungsfälle realisieren.
Graphische Darstellung
Systemname
Akteure:
‐ Rolle die ein Nutzer oder ein anderes System einnimmt, die mit dem zu entwickelndem System
interagiert.
‐ liegt außerhalb des Systems
Zwischen Akteur und Anwendungsfall findet ein wechselseitiger Austausch von Daten und
Nachrichten statt.
QIS:
Student, Dozent, Mitarbeiter im
Prüfungsamt, Administrator,…
Akteur
31
Beziehungen zwischen Akteuren

Generalisierung bzw. Spezialisierung
Beziehungen zwischen Akteur und Anwendungsfall werden vererbt
Anwendungsfall
Engl. Use Case
‐ Menge von Aktionen in einem zusammenhängenden Arbeitsablauf, den ein Akteur mit dem System
ausführen kann
‐ abgeschlossene Teilfunktionalität des Systems
‐ Anwendungsfall wird immer von einem Akteur ausgelöst
‐ Ein Anwendungsfall führt zu einem für den Akteur wahrnehmbaren Ergebnis
‐ Anwendungsfall kann mehrfach instanziiert werden
Beziehungen zwischen Akteuren und Anwendungsfällen

‐ verbinden die Akteure mit den Anwendungsfällen
‐ Beziehungen können gerichtet sein
‐ Multiplizitäten können den Beziehungen zugeordnet werden
Beispiel:
32
Beziehungen zwischen Anwendungsfällen

Generalisierung bzw. Spezialisierung
Idee: Darstellung einer Funktionalität auf höherer Ebene ohne in die Einzelheiten zu gehen
Beispiel
Abstrakter Noten bearbeiten

Anwengungsfall
Konkrete
Anwendungs-
fälle Noten erfassen Noten löschen Noten ändern
Enthaltensbeziehung zwischen Anwendungsfällen (include)

Idee: Herausziehen gemeinsamer Funktionalität aus Anwendungsfällen und kreieren eines neuen
Anwendungsfalls
<<
inc
lud
e>
>
Erweiterungsbeziehungen zwischen Anwendungsfällen (extent)

Idee: Ergänzung zusätzlicher Funktionalität zu einem Anwendungsfall unter bestimmten
Bedingungen:
33
5. Übung
Aufgabe 1
Interpretieren Sie das folgende Anwendungsfalldiagramm:
Antwort:
‐ Akteur
‐ Anwendungsfall / Use case
‐ Erweiterungspunkte / Extension Points
Beobachtung
Im Anwendungsfall "Kunden bearbeiten" wir immer der Anwendungsfall "Kunden auswählen"
ausgeführt.
Der Anwendungsfall hat zwei Erweiterungspunkte:
Neu: Neuer Kunde, der noch nicht im System erfasst ist
Trifft die Bedingung zu, wird der Anwendungsfall um den Anwendungsfall "Kunde
erfassen" erweitert.
Obsolet: ANALOG
Welche Erweiterungsbeziehung betrachtet werden muss, ist hier über Kommentare kenntlich
gemacht
34
Aufgabe 2
Sie arbeiten als Systemanalyst in einem Softwareprojekt. Ziel ist es, ein Bibliothekssystem
für die Ausleihe zu entwickeln. Sie sind für die Erstellung und Dokumentation des
Anwendungsfallmodells gemäß der Unified Modeling Language verantwortlich.
a) Geben Sie Beispiele für Akteure und beschreiben Sie diese kurz! Entwickeln Sie eine
strukturierte Beschreibungsform für Akteure.
Beschreibung:
Akteure/Rolle: Professor
Typ: Person System
Beschreibung:
Kontakt:
Ansprechpartner: Herr X
Frau Y
…
b) Identifizieren Sie geeignete Anwendungsfälle!

Buch ausleihen
Buch suchen
Kunde bearbeiten (löschen/anlegen)
System anmelden
System abmelden
Buch zurückgeben
Mahnung versenden
Leihfrist verlängern
Buch aufnehmen
Buch entfernen
Mahngebühren berechnen
Buch vormerken
Rückforderung versenden
35
Vormerkung bestätigen
c) Ein Szenario beschreibt eine spezifische Folge von Aktionen, die zur Verdeutlichung
des Verhaltens eines Systems führen. Szenarien sind Beispiele aus dem
Anwendungsbereich, die Ausgangspunkt für Abstraktion und Spezifikation sind. So ist
beispielsweise das Ausleihen eines konkreten Buches durch einen konkreten
Studenten zu weiteren konkreten Rahmenbedingungen ein Szenario. Ein Szenario ist
damit eine mögliche Ausprägung eines Anwendungsfalls. Szenarien helfen die
abstrakte Beschreibung zu verdeutlichen bzw. zu verdeutlichen. Beschreiben Sie ein
Szenario Buch ausleihen!
Ausgangslage:
Medium ausleihen
Herr X leiht das Buch Y aus. Frau Z bearbeitet den Ausleihvorgang

1. Herr X übergib eine Benutzerkarte
2. Frau Z scannt den Barcode von der Karte ein
3. Frau Z überprüft das Benutzerkonto
4. Herr X übergibt das Buch Y
5. Frau Z überprüft den Ausleihstatus
6. Frau Z scannt das Buch ein
7. Frau Z bestätigt die Leihfrist
8. Frau Z entsichert das Buch
9. System druckt den Ausleihbeleg
36
10. Frau Z überreicht das Buch mit Beleg an Herr X

Alternative Szenarien: Normalter Ablauf…
Alternativer Ablauf…
Abstraktion von Ausgangslage
Herr X Æ Kunde
Frau Z Æ Bib.‐Mitarbeiterin
Buch Y Æ Buch (Medium)
Vorbedingungen:
‐ Kunde ist registriert
‐ Buch ist ausleihbar
Nachbedingung
‐ Buch ist ausgebucht
d) Leiten Sie aus dem Szenario eine Beschreibung für den Anwendungsfall Buch
ausleihen ab. Verwenden Sie die in der Vorlesung vorgestellte Vorlage.
‐‐‐‐NICHT BEHANDELT‐‐‐‐
e) Erstellen Sie ein Anwendungsfalldiagramm, das die Beziehungen zwischen Akteuren
und Anwendungsfälle beschreibt.
‐‐‐‐NICHT BEHANDELT‐‐‐‐
37
7. Aktivitätsdiagramme
Motivation:
Bei der Spezifikation der Anwendungsfälle werden Abläufe und alternative Abläufe beschrieben.
Manchmal sind die Abläufe sehr komplex wegen Bedingungen, Wiederholungen, Sprüngen,… in der
Abfolge der Einzelschritte.
Textuell schwierig zu beschreiben
Lösung: Aktivitätsdiagramm als Ergänzung zur textuellen Beschreibung
Diagrammtyp: Verhaltensdiagramm
Ziele: Aktivitätsmodellierung stellt die Ausführung und den Verhaltensablauf in den Mittelpunkt der
Modellierung und nicht die Zusammensetzung des Systems.
Was kann man als Aktivität modellieren?
‐ Abläufe, die Anwendungsfällen zugeordnet sind
‐ Geschäftsprozesse
‐ Algorithmen bzw. Verhalten (Abfolge der Schritte) einer Operation
Anwendung: Analysephase auch Designphase
Notationselemente:
Aktivität
‐ beschreibt eine Menge von Abläufen, die z.B. ein System bei der Ausführung durchlaufen
kann
38
Wichtige Bestandteile
‐ Aktionsknoten
‐ Objektknoten
‐ Kontrollknoten
Die Knoten sind durch Objekt‐ und Kontrollflüsse verbunden
Aktion:
‐ Einzelschritt in einer Aktivität
‐ Aufruf eines Verhaltens, das mit der Bearbeitung von Daten verbunden ist
‐ Aktionen werden nicht weiter belegt
Darstellung: Bsp. –math. Fkt y=xa

A k tio n s n a m e ‐Abarbeiten eines Algorithmus: Sortiere
‐ Aufruf von Verhalten, dass als Aktivität
modelliert ist
A k tio n
A k tiv itä ts n a m e
Weitere Beispiele:
‐ Umsatzsteuer berechnen
‐ Bestellung versenden
‐ X=x+1
‐…
Nach Ausführung einer Aktion geht die Steuerung gemäß dem Kontrollfluss an die nachfolgende
Aktion über.
39
Kontrollknoten:
Startknoten
‐ Startpunkt eines Ablaufs
‐ Aktivität kann bel. viele Startknoten besitzen
‐ Es werden nebenläufige Prozesse ausgelöst
‐ kann bel. viele ausgehende Kontfl. Haben
‐ Aktivität muss keine Startknoten haben
Endknoten für eine Aktivität
‐ beendet die Aktivität d.h. es werden auch
parallele Abläufe direkt beendet
Endknoten für einen Ablauf
Parallelisierungsknoten (Fork Node)
‐ ein eingehender Kontrollfluss wird ohne
Bedingung in mehrere ausgehende
Kontrollflüsse aufgeteilt
Synchronisationsknoten (Join Node)
‐ parallele Kontrollflüsse werden am
synchronisationsknoten durch ein impliziertes
„und“ zusammengesetzt
Spezielle Synchronisation
‐ Es wird erst fortgefahren, wenn alle
Kontrollflüsse eingegangen sind
Verzweigungsknoten
‐ Aufspaltung eines Kontrollflusses nach
verschiedenen Bedingungen
‐ Verwendung, wenn der Kontrollfluss von
Bedingungen abhängt
‐ Bedingung müssen sich gegenseitig
ausschließen
‐ Verhalten lässt sich durch Kommentare näher
spezifizieren
Verbindungsknoten
‐ Gegenstück zum Verzweigungsknoten
‐ Jeder der mögliche eingehenden
Kontrollflüssen führt sofort zu einem
ausgehenden Kontrollknoten
40
6. Übung
Aufgabe 1
Für die Personalabteilung eines mittelständischen Unternehmens soll eine neue Software
für die Personalabteilung entwickelt werden. Eine wichtige Komponente in diesem System
ist die Verwaltung der Urlaubsansprüche der einzelnen Mitarbeiter. In der Dokumentation
eines entsprechenden Anwendungsfall Urlaubsanspruch verwalten wird auf den
folgenden Auszug aus einem Bundes‐Tarifvertrag verwiesen:
Der Mindestanspruch beträgt auf Basis einer Fünf‐Tage‐Woche:
1. für Arbeitnehmerinnen vor Vollendung des 30. Lebensjahres 26 Werktage
Der Mindestanspruch erhöht sich jedes Jahr der Betriebszugehörigkeit mit vollem
Urlaubsanspruch um einen Urlaubstag.
1. für Arbeitnehmerinnen vor Vollendung des 30. Lebensjahres bis zu höchstens
29 Werktagen
Beschreiben Sie die Bestimmung des Urlaubanspruchs in Abhängigkeit von Alter und
Anzahl der Jahre der Betriebszugehörigkeit eines Mitarbeiters als Aktivitätsdiagramm.
Antwort: Siehe Übung 3 Aufgabe 4
41
Aufgabe 2
In der letzten Vorlesung wurde für ein Bibliothekssystem verschiedene Anwendungsfälle
identifiziert. Einer der Anwendungsfälle war Leihfrist verlängern. Beschreiben Sie den
dem Anwendungsfall zugeordneten Ablauf als Aktivitätsdiagramm.
Die Bibliotheksleitung hat hierzu folgende Geschäftsregeln formuliert:
Leihfrist:
Die Leihfrist für Bücher beträgt 21 Tage, für audio‐visuelle Medien 7 Tage. Gebundene
Zeitschriften können ebenfalls 7 Tage entliehen werden. Ungebundene Zeitschriften und
Zeitungen können für 1 Tag entliehen werden.
Die Leihfrist kann persönlich, per E‐Mail oder telefonisch bis zu zwei Mal verlängert
werden, falls keine Vormerkung eines anderen Bibliotheksbenutzers vorliegt. Die Leihfrist
von Präsenzbeständen sowie von Zeitschriften und Zeitungen kann nicht verlängert
werden. Verlängerte Medien können jederzeit zurückgefordert werden. Bei der Bitte um
Verlängerung Matrikelnummer, Leihfristende und Signatur angeben. Bei Überschreiten
der Leihfrist fällt ohne vorherige Mahnung pro Band pro angefangene Woche eine
Säumnisgebühr von € 1,00 an.
42
Aufgabe 3
Die Modellierung der Aktivität Mitarbeiter einstellen beinhaltet folgende Aktionen:
• Einstellungsvertrag unterschreiben
• Mitarbeiter an Sozialversicherung melden
• Benutzerkonto einrichten
• Arbeitsplatz ausstatten
• Übergabe von Benutzerkonto und Ausstattung bestätigen
Erstellen Sie ein entsprechendes Aktivitätsdiagramm!
Antwort:
43
8. Klassendiagramme
Bei der objektorientierten Software‐ Entwicklung werden Objekte identifiziert und zu Klassen
zusammengefasst.
Objekt: Gegenstand aus Problembereich, in dem die Software eingesetzt werden soll.
Eigenschaften (Å Attributwerte) legen den Zustand eines Objektes fest.
Verhalten eines Objektes wird über Operationen beschrieben.
Ein Objekt hat eine Identität, die es von allen anderen Objekten unterscheidet.
Klasse: Sammlung von Objekten mit gleichen Attributen, Operationen und Beziehungen.
Details in Prog 3
Wie kann man Klassen bzw. Beziehungen zwischen Objekten der Klassen modellieren?
Antwort: Klassendiagram
Diagrammtyp: Strukturdiagramm
Ziel: Darstellung der Struktur eines Softwaresystems auf Grundlage der Klassen.
Anwendung:
1. Analysephase
Klassendiagramm beschreibt die wesentlichen Klassen des Systems und die Beziehungen
zwischen den Klassen. Auf Details wird in der Darstellung oftmals Verzichtet (z.B. keine techn.
Attribute, keine Operationen, keine "Hilfsklassen",…)
2. Spätere Phasen
Klassendiagramm ist Grundlage für die technische Realisierung (Erzeugung des Quellcodes).
Hierzu müssen auch die technischen Details beschrieben werden.
Notationselemente
Klasse
Zentrales Element im Klassendiagramm
Darstellung
Klassenname
Attribute
Operationen
Klassenname Klassenname Klassenname
Attribute Operationen
Über Stereotypen können Klassen spezifiziert werden
<<entity>> <<controlle>>
Stereotyp
Klassenname Klassenname
Entity‐Klasse
Controller‐Klasse
Attribute Attribute
Operationen Operationen
Attribute:
Attribute Deklaration:
[Sichtbarkeit] [/]name[:Typ] [[Multiplizität]] [Vorgabewert] [{Eigenschaftswert}]
[]=optional
Sichtbarkeit:
+ publik (öffentlich, alle Klassen können darauf zugreifen)
‐ private (nur die Klasse selbst hat Zugriff auf das Attribut)
# protected (auch abgeleitete Klassen haben Zugriff auf das Attribut)
~ package (alle Klassen im gleichen Paket haben Zugriff auf das Attribut)
44
Abgeleitetes Attribut:
/ (benötigt in der Regel keinen Speicherplatz Bsp: alter = akt.Datum – geb. Datum)
Name: klein geschriebene Name des Attributs
Multiplizität:
0…1
0…*
1…*
n…m
Vorgabewert:
‐ Default‐Wert für ein Attribut
Eigenschaftswert
‐ read Only (Wert darf nicht geändert werden)
‐ ordered (Attributwerte in geordneter Reihenfolge)
Klassenname
alt1
+ alt2:int
+ p: double = 3,14
‐ alt3: String [0…*] {read only}
Operationen
Operationsdeklarationen:
[Sichtbarkeit]name([Parameterliste]) [:[Rückgabetyp] {Eigenschaftswert}]
Parameterliste: kann auch detailliert spezifiziert werden: ‐ Übergaberichtung
‐ Name
‐ Typ
‐ Multiplizität
‐…
Beispiel :
Klassenname
+ op1()
‐op2(in param1/:int = 5):int
#op3 (param2:Klasse)
.
.
.
45
Modellierung der Beziehungen zwischen Objekten

Es gibt unterschiedliche Arten von Beziehungen
Assoziation:
‐ Modellierung der Verbindung zwischen Objekten
‐ binäre Assoziation verbindet zwei Objekte
‐ reflexive Assoziation verbindet zwei Objekte einer Klasse
Darstellung:
Beispiel:
Mögliche Multiplizitäten:
genau 1
0 bis 1
0 bis viele
1 bis viele
n bis m
46
Assoziation
Navigierbarkeit
Festlegung, ob eine Assoziation uni‐ oder bidirektional implementiert wird
a) unidirektionale Assoziation
1 *
Class A Class B
Pfeilspitze gibt die Navigationsrichtung an. D.h. von Class B kann zu Class A navigiert werden
Bedeutung: Objekt der Class B kann auf Objekte der Class A, mit denen es in "Verbindung" steht,
zugreifen.
Mit einem Kreuz an einem Assoziationsende, kann man die Navigation von einer Klasse zu einer
anderen Klasse verbieten. In unserem Fall: Navigation von Class A zu Class B ist nicht möglich. D.h.
Objekt der Class A kennt nicht die Objekte der Class B, mit denen es in Verbindung steht.
Beispiel:
b) Bidirektionale Assoziation
meistens
Es kann sowohl von Class A zu Class B navigiert werden als auch von Class B zu Class A. In der Regel
wird keine "Pfeilspitze" mit navigierbarkeit gleichgesetzt.
47
Neben der Assoziation gibt es noch die Aggregation und Komposition.

Aggregation
beschreibt eine Teil‐ Ganzes‐ Beziehung im Sinn von "besitzet ein …"
Komposition
beschreibt auch eine Teil‐ Grenze‐ Beziehung im Sinn von "ist Teil von …"
Wichtig: Wenn das Objekt der Aggregatklasse gelöscht wird, können die Objekte der
Teilklasse nicht mehr existieren und müssen auch gelöscht werden.
=> existenzabhängiges Teil
Beispiel:
48
Übung 7
Aufgabe 1
Gegeben sind die Klassen Kunde, Kundenauftrag, Kundenauftragsposition, Anschrift,
Rechnung und Artikel.
a) Erstellen Sie ein Klassendiagramm mit den obigen Klassen. Ergänzen Sie sinnvolle
Assoziationen!
b) Benennen Sie Ihre Assoziationen!
c) Ordnen Sie den Assoziationen Multiplizitäten zu!
Aufgabe 2
Sie sollen im Folgenden Klassen und Beziehungen zwischen Klassen, die für ein
Bibliothekssystem benötigt werden modellieren.
a) Modellieren Sie die Klassen Buch und Benutzer.
b) Geben Sie Beispiele für Attribute!
c) Geben Sie Beispiele für Operationen!
49
Aufgabe 3
UML bietet die Möglichkeit Assoziationen mit sogenannten Constraints (Zusicherungen,
Restriktionen) zu versehen. Das folgende Klassendiagramm zeigt ein Beispiel.
Geben Sie eine Interpretation!
Aufgabe 4
Gegeben sind im Folgenden verschiedene Klassen. Entscheiden Sie welche Art von
Verbindung zwischen Objekten der Klasse sinnvoll erscheint:
a) Gegeben sind die Klassen Haus und Zimmer. Welche Art der Assoziation würden Sie
modellieren?
• Eine einfache Assoziation hat Beziehung zu
• Eine Aggregation besteht aus
• Eine Komposition besteht aus
b) Gegeben seien die Klassen Computer, CPU und Display. Welche Art von Assoziation
würden Sie modellieren?
• Eine einfache Assoziation besitzt
• Eine Aggregation setzt sich zusammen aus
50
c) Gegeben seien die Klassen Funktion, Funktionskopf und Funktionsrumpf. Welche Art
von Assoziation würden Sie modellieren:
• Eine einfache Assoziation besteht aus
• Eine Aggregation besteht aus
Aufgabe 5
Die Aufbauorganisation eines Unternehmens besteht aus Funktionsbereichen, die in
Hauptabteilungen untergliedert sind. Hauptabteilungen sind in Abteilungen untergliedert.
Abteilungen sind wiederum in Gruppen untergliedert. Den Gruppen sind Mitarbeiter
zugeordnet. Erstellen Sie ein entsprechendes Klassendiagramm ohne Angaben von
Attributen und Operationen.
51
Modellierung der Vererbung

Sinn: Wiederverwendbarkeit, Verständnis
Klassen kann man in eine Hierarchie einordnen, die eine "Weiterleitung von Informationen von oben
nach unten" ermöglicht.
Zentrales Konzept der objektorientierten Programmierung
Idee: Eigenschaften der Oberklasse werden an die Unterklassen vererbt.
Beispiel:
Generalisierungsbeziehungen haben keine Multiplikatoren
52
Was wird alles vererbt?

Beispiele:
‐ Attribute
‐ besitzen alle Objekte der Oberklasse ein Attribut A, dann besitzen auch alle Objekte der
Unterklasse das Attribut
‐ besitzt die Oberklasse ein Klassenattribut mit dem Wert w, dann auch die Unterklasse
‐ Operationen
‐ alle Operationen, die auf Objekte der Oberklasse angewendet werden können, können auch
auf die Unterklasse angewendet werden
‐ Klassenoperationen,…
‐ Assoziationen
Existiert eine Assoziation zwischen der Oberklasse und einer anderen Klassen, dann wird die
Assoziation an die Unterklasse vererbt
Beispiel:
Diskriminationen
‐ Entspricht einem Unterscheidungsmerkmal zur semantischen Strukturierung von
Generalisierung bzw. Spezialisierungsbeziehungen.
‐ legen die Rolle fest, die die Unterklasse für die Oberklasse spielt
53
Angestellter
Arbeitszeit Tätigkeit
Vollzeitkraft Teilzeitkraft Aushilfskraft Manager Sozialarbeiter
Vererbung kann von Zusicherungen ergänzt werden
Beispiel:
Complete: alle sinnvollen Spezialisierungen eines Typs nach einem Diskriminators sind im Modell
eingestellt.
disjoint: keine Instanz einer Unterklasse ist gleichzeitig Instanz einer anderen Unterklasse unter
einem Diskriminator
overlapping: Es kann Instanzen geben, die Ausprägungen von mehr als einer Unterklasse sind.
Arten von Klassen:

Klassen, die nichtinstanziiert werden können, bezeichnen wir als abstrakte Klassen. Zu einer solchen
Klasse gibt es keine Objekte.
Umgekehrt: Klassen, zu denen Objekte erzeugt werden können, bezeichnen wir als konkrete Klassen.
Abstrakte Klassen werden benötigt, um Informationen in Vererbungshierarchien zu strukturieren.
Mit ihr können Gemeinsamkeiten von Unterklassen dargestellt werden.
Darstellung:
Wann hat man eine abstrakte Klasse verwendet werden?

‐ eine Klasse, die eine abstrakte Operation besitzt, ist eine abstrakte Klasse (Einer normalen
Klasse kann nie eine abstrakte Operation zugeordnet werden)
‐ wenn keine Instanzen gebildet werden soll
‐…
54
Beispiel:
Assoziationen sind möglich!
Interfaces
‐ dürfen keine Attribute haben
‐ keine Assoziationen, bzw. können höchstens Ziel einer einseitig navigierbaren Assoziation
sein (kann Pfeil drauf gehen, aber nicht davon weg)
Darstellung:
55
8. Übung
Aufgabe 1
Die Unified Modeling Language bietet die Möglichkeit der attributierten Assoziationen
zwischen Klassen. Damit ist es möglich Assoziationen mit Eigenschaften zu versehen.
Eine attributierte Assoziation wird dann über eine Assoziationsklasse dargestellt. Die
Darstellung wird durch folgendes Beispiel verdeutlicht:
Die Assoziationsklasse Ausleihe hat die beiden Attribute Datum und

Anzahlverlängerungen. Es ist auch möglich einer Assoziationsklasse Operationen
zuzuordnen. Die Assoziationsklasse ist über eine gestrichelte Linie mit der Assoziation
verbunden.
Entwickeln Sie ein Transformationsschema, um Assoziationsklassen in „reguläre“ Klassen
zu übertragen. Definieren Sie hierzu für die unten stehenden Fälle a) und b) entsprechende
Transformationsregeln.
a) b)
56
Aufgabe 2
Bei der Analyse der Geschäftspartnerverwaltung in einem betrieblichen
Anwendungssystems werden Sie auf verschiedene Anschrifttypen hingewiesen. Es gibt
inländische und ausländische Anschriften. Bei inländischen Anschriften gibt es wiederum
spezielle Anschriften für Großkunden, Postfächer und Paketzustellungen. Modellieren Sie
eine entsprechende Spezialisierungshierarchie. Ordnen Sie Ihren Klassen sinnvolle
Attribute zu und beschriften Sie die Spezialisierungshierarchien mit Diskriminatoren.
Fachhochschule Trier, Umwelt‐Campus Birkenfeld
Software Engineering
Aufgabe 3
In unserer Bibliothek werden Bücher, audio‐visuelle Medien, Zeitschriften und Sonderbestände
verwaltet.
a) Modellieren Sie für die angegebenen Medien Klassen mit entsprechenden Attributen
und Operationen.
b) Entwickeln Sie eine entsprechende Spezialisierungshierarchie. Prüfen Sie, ob in Ihrem

Modell zur Strukturierung abstrakte Klassen sinnvoll eingesetzt werden können.
c) Fügen Sie zu Ihrem Modell eine Klasse Bibliotheksnutzer mit entsprechenden

Assoziationen hinzu.
57
Aufgabe 4
Eine Enumeration ist eine Menge fester Werte ohne weitere Eigenschaften. Man kann sie
verwenden, um Farben, Größen, Statusbezeichnungen etc. zu modellieren. Sie werden in
der Unified Modeling Language als Enumerationsklasse wie folgt dargestellt:
Modellieren Sie eine Enumerationsklasse, die den (Ausleih‐)status eines Buches in einer
Bibliothek beschreibt.
Aufgabe 5
In Windows XP kann ein Verzeichnis Dateien, Verzeichnisse und Verknüpfungen
enthalten. Erstellen Sie ein entsprechendes Klassendiagramm. Beachten Sie, dass wenn
ein Verzeichnis gelöscht bzw. kopiert wird, immer alle darin enthaltenen Objekte gelöscht
bzw. kopiert werden müssen.
* Dateiobjekt * 1 Wurzelverzeichnis
- erstellt am
- Größe
- Art
- Name
Ordner Datei Verknüpfung
- Dateianzahl - letzter Zurgriff - Zielobjekt

0...1 - geändert am
58
9. Zustandsdiagramme
Motivation: Bei vielen Systemen ist das Systemverhalten abhängig von der Eingabe und dem Zustand,
in dem sich das System aufgrund von vorangegangenen Eingaben befindet.
Beispiele: ‐ Digitaluhr
‐ Getränkeautomat
‐ Objekt der Klasse Buch
In diesen Fällen kann das Verhalten durch ein Zustandsdiagramm beschrieben werden.
Diagrammtyp: Verhaltensdiagramm
Ziele: Spezifikation des Verhaltens eines Systems, Subsystems, Komponente, Objekte einer Klasse,
Anwendungsfall,… in einem bestimmten Zustand bei verschiedenen Ereignissen.
In UML gibt es 2 Arten von Zustandsdiagrammen
‐ Darstellung von Verhaltens‐ Zustandsautomaten
‐ Darstellung von Protokoll‐ Zustandsautomaten
Grundlagen
Zustandsautomaten sind eine Erweiterung der Endlichen Automaten. Die Automaten haben im
Hardware‐ und Softwareentwurf eine hohe Bedeutung.
In der Theorie sind die Automaten mathematische Modelle:
‐ Endlischer Automat
‐ Mealy – Automat (den Zustandsübergängen sind Ausgaben zugeordnet)
‐ Moore – Automat (Ausgaben sind den Zuständen zugeordnet)
Harel hat Mealy‐ und Moor Automaten erweitert. Sie bilden die Grundlage für die
Zustandsautomaten in UML.
Beispiel Mealy – Automat
Zustand
Ausgabe: 1 q2 Berechnung des Rest bei der
2 q3
2 q3 ganzzahligen Division durch 3
1 q2
0 q1
1 q2
Zustandsautomaten in UML
Notationselemente
‐ Zustände
‐ einfache Zustände
‐ Pseudozustände
‐ Transitionen
‐ u.a.
59
Einfache Zustände
‐ Ein Zustand bildet eine spezielle Situation ab
‐ Zustände werden durch das Eintreten bestimmter Ereignisse verlassen
‐ Zustand ist entweder aktiv oder inaktiv
Beispiel: Identifizierung der Zustände bei Klassen
Zustände entsprechen den Werten von

Attributkombinationen.
Es müssen nicht alle Attribute berücksichtigt werden.
Graphische Darstellung von Zuständen
Erläuterung
‐ Ein Zustand kann einen Namen haben
‐ Einem Zustand kann Verhalten zugeordnet werden
‐ Zustand wird über eine Transition, die ihm als Ziel hat, betreten, wenn ein der Transition
zugeordnetes Trigger‐Ereignis Auftritt. Der Zustand ist dann aktiv
‐ Zustand wird über eine Transition, die vom Zustand wegführt, verlassen, wenn ein der
Transition zugeordnetes Trigger‐Ereignis auftritt. Der Zustand ist dann inaktiv.
‐ Beim Betreten des Zustands wird als erstes das Eintrittsverhalten ausgeführt
‐ Beim Verlassen wird das Austrittsverhalten ausgeführt. Nach Beendigung des
Eintrittsverhaltens wird das Zustandsverhalten ausgeführt
Transitionen
‐ Trigger: Auslöser für eine Transition. Einzelne Trigger werden durch Kommata getrennt.
Trigger entspricht dem Eintreten eines bestimmten Ereignisses. Beispiele: Call
Trigger, Time Trigger, Change Trigger, Signal Trigger
‐ Guard: Festlegung von Bedingungen, die erfüllt sein müssen, damit eine Transition
durchlaufen werden kann.
‐ Verhalten: Das Verhalten, z.B. Aktivität, das beim Durchlaufen der Transition ausgeführt wird.
60
Spezielle Zustände:
Startzustand: ‐ Startpunkt beim Betreten des Zustandsautomaten
Darstellung: ‐ muss genau einmal vorkommen
‐ keine eingehende Transition
‐ ausgehende Transitionen können Guards und Verhalten haben
Endzustand: ‐ wenn der Endzustand erreicht wird, ist die Abarbeitung des Automaten
beendet
Darstellung: ‐ haben keine ausgehende Transitionen
‐ es kann mehrere Endzustände geben
Hinweis: Verlassen eines Zustandsautomaten, der ein Objekt beschreibt, sollt
die Lebensdauer des Objekts beenden.
61
Übung 9
Aufgabe 1
Gegeben ist der folgende Auszug aus der Bedienungsleitung einer Digitaluhr:
Erstellen Sie ein Zustandsdiagramm zur Verhaltensbeschreibung dieser Digitaluhr.

Antwort:
62
63
Aufgabe 2
Beschreiben Sie das Verhalten von Objekten der Klasse Buch aus Übung 7 / Aufgabe 2
über ein Zustandsdiagramm.
64
Hinweise zur Entwurfsphasen
Entwurf: Umsetzung der Anforderungsspezifikation in eine SW‐Architektur, die die Grundlage

für die spätere Implementierung ist
Vorgehen: Zerlegung des Gesamtsystems in kleinere Komponenten. Z.B. Teilsysteme, Klassen,
Module,…
Teilsysteme: Zusammenfassung von Modulen zu einem unabhängigen Ganzen,
mit der zusätzlichen Angabe der Schnittstellen zu Nutzung der
Modulfunktonalität.
SW Architektur spezifiziert insbesondere die Funktionalität einer Komponente und das Verhalten
einer Komponente
Beschreibung in UML
Strukturdiagramme
Beschreibung der SW‐ ‐ Paketdiagramme
Architektur auf einer
hohen Abstraktionsebene
{ ‐ Komponentendiagramme
Kriterien für eine gute Architektur

‐ jede Komponente sollte ein logisch zusammenhängendes Teilproblem behandeln
‐ Abhängigkeit zwischen den Komponenten sollte möglichst gering sein
Qualitätskriterien
‐ Kopplung: Komplexität der Beziehungen in einer modularen Architektur
Ziel: Schmale Schnittstellen über die wenige Daten fließen
Also: Maß für die Komplexität von Schnittstellen
‐ Kohäsion: Maß für den logischen Zusammenhang, der in einem Modul realisierten
Aufgaben
Ziel: Starke Kohäsion, schwache Kopplung
65
PDF „V09.php“ von FS‐DOMAIN einfügen!!!!!!!!!!! \krieger\ws07\SOFTENG\v09.pdf
66
Manuelle Prüfmethoden
Literatur: Balzert, H.: Lehrbuch der Software‐Technik (2. Band)
G.J. Myers: Methodisches Testen von Programmen
Semantische Überprüfungen müssen in der Regel Manuell vorgenommen werden.

Z.B. Qualitätsmerkmale wie
‐ Verständlichkeit
‐ Aussagefähigkeit
von Bezeichnern und Kommentaren.
Human Testing gehört zu den manuellen Prüfmethoden:

‐ Inspektion
‐ Review
‐ Walkthrough
Oft wird der Begriff Review als Oberbegriff verwendet. Ein Review (hier: Oberbegriff) ist eine formell
organisierte Zusammenkunft von Personen zur inhaltlichen oder formalen Prüfung einer Software‐
Einheit (Programm, Dokument) nach vorgegebenen Kriterien:
‐ Technische Reviews: Prüfung der Erreichung von Sachzielen
‐ Management Reviews: Prüfung der Erreichung von Terminen und der Einhaltung von Kosten.
Es wird über das weitere Vorgehen entschieden.
Eigenschaften:
‐ Produkte, Teilprodukte werden manuell analysiert, geprüft und begutachtet.
‐ Ziel ist es, Fehler, Defekte, Inkonsistenzen und Unvollständigkeiten zu finden.
‐ Überprüfung erfolgt in einer Gruppensitzung durch ein kleines Team mit definierten Rollen.
Voraussetzungen:
‐ Aufwand und benötigte Zeit müssen fest eingeplant sein.
‐ Mitglieder müssen in der Prüfmethode geschult sein.
‐ Prüfergebnisse werden nicht zur Beurteilung von Mitarbeitern benutzt.
‐ Schriftliche Festlegung der Prüfmethode
‐ Vorgesetzte und Zuhörer sollen an den Prüfungen nicht teilnehmen.
Warum manuelle Prüfmethoden?
Manchmal:
Inspektionen, Reviews und Walkthrough nur neue Bezeichnungen für den klassischen
Schreibtischtest (Prozess, in dem der Programmierer sein eigenes Programm überprüft, bevor er
testet)
‐ Inspektionen, Reviews und Walkthroughs sind aber wesentlich effektiver, weil andere
Personen als der Autor an diesem Prozess beteiligt sind.
‐ Ergeben auch niedrigere Korrekturkosten, da bei einer Fehlerentdeckung die exakte Natur
des Fehlers festgestellt wird (Test mit Computer zeigt nur die Symptome)
‐ Es werden 30 ‐ 70% der logischen Entwurfs‐ und Codierungsfehler gefunden.
‐ Nicht sehr effektiv bei der Überprüfung von Anforderungen.
‐ In IBM ‐ Projekten: Wirkungsgrad von 80% bei der Fehlerentdeckung (100% = Fehler, die
beim Abschluss der Tests gefunden wurden)
67
Durchführung einer Inspektion
1. Inspektion beantragen
‐ Moderator auswählen
‐ muss für diese Tätigkeit ausgebildet sein.
‐ nicht der Vorgesetzte
2. Eingangskriterien
‐ Ist eine Inspektion überhaupt sinnvoll?
3. Planung
‐ Festlegung und Einladung des Inspektionsteams
‐ Festlegung und Zuordnung von Rollen an jeden Inspektor
Beispiele: Benutzer: Konzentration auf Benutzersicht,
Finanzen: Konzentration auf die Kostenimplikationen
Qualität: Konzentration auf die Aspekte von Qualitätsmerkmalen
Service: Konzentration auf Wartung und Installation
‐ Festlegung der notwendigen Referenzunterlagen für die Inspektion (Ursprungsprodukt,
Erstellungsregeln, Checklisten, Inspektionsregeln)
‐ Festlegung von Terminen
4. Einführungssitzung
‐ dem Inspektionsteam, notwendige Informationen zu vermitteln und die zu erledigenden
Aufgaben zu erläutern.
5. Individuelle Vorbereitung und Prüfung
‐ Vorbereitung muss bis zur Inspektionssitzung abgeschlossen sein.
‐ Prüfobjekt ist auf spezielle Defekte hin zu untersuchen, die sich aus der zugewiesenen Rolle
ergeben.
‐ Überprüfung ist entsprechend den Inspektionsregeln vorzunehmen.
‐ Gefundene Defekte sind zu notieren
‐ Arbeitsgeschwindigkeit: ca. 1 Seite/h
‐ auf schwere Defekte konzentrieren
‐ Wichtig: ohne individuelle Vorbereitung findet man nur ca. 10% der Defekte
6. Inspektionssitzung
‐ Brainstorming Sitzung: keine Sammlung von Ideen aber von Defekten
‐ Vorleser liest Prüfobjekt abschnittsweise vor
‐ Identifizieren und protokollieren potentieller Defekte
‐ Protokollführer soll kein Inspektor sein.
7. Überarbeitung und Nachkontrolle
‐ Behebung der Schwachstellen durch den Autor
‐ Nach‐Inspektion, falls erforderlich sonst Freigabe durch den Projektleiter.
68
Zusammenfassung (Inspektion)
Manuelle Prüfmethode mit definiertem Ablauf:

‐ individuelle Vorbereitung der Gutachter
‐ Diskussion/Brainstorming in einer Teamsitzung
Ergebnisprotokoll der Inspektionssitzung:
‐ Inspektionsdatum
‐ Name des Moderators
‐ Prüfobjekt
‐ Referenzunterlagen
‐ Defekte mit folgenden Angaben:
Kurzbeschreibung des Defekts
Ort des Defekts
Bezug zu Regeln und Checklisten
leichter/schwerer Fehler
in Sitzung identifiziert/in Vorbereitung identifiziert
Verbesserungsvorschläge
Fragen an den Autor
Empirische Ergebnisse
‐ 50 ‐ 75% aller Entwurfsfehler können durch Inspektionen aufgedeckt werden.
‐ Code ‐ Inspektionen sind kosteneffektiv
‐ effektivste Methode unter den statischen Verfahren
‐ Inspektionen sollten frühzeitig durchgeführt werden während eines Projektes.
Walkthrough
Structured Walkthrough
‐ manuelle, informale Prüfmethode
‐ Identifizierung von Fehlern, Defekte, Unklarheiten und Probleme in schriftlichen
Dokumenten
‐ Abgeschwächte Form eines Reviews.
Walkthrough ‐ Sitzung:
‐ Autor leitet als Moderator die Sitzung
‐ Zu Beginn erhalten die Gutachter das Prüfobjekt
‐ Autor stellt das Prüfobjekt Schritt für Schritt vor.
‐ Bei einem Programm werden typische Anwendungsfälle ablauforientiert durchgegangen.
‐ Gutachter stellen spontane Fragen und versuchen so, mögliche Probleme zu identifizieren.
‐ Probleme werden protokolliert.
Bewertung
Vorteile:
‐ geringer Aufwand
‐ für kleine Entwicklungsteams geeignet
‐ sinnvoll für unkritische Dokumente
‐ durch Einbeziehung von Endbenutzern als Gutachter können Unvollständigkeiten und
Missverständnisse aufgedeckt werden.
‐ Gut geeignet, um Wissen über ein Dokument auf eine breite Basis zu stellen.
Nachteile:
‐ Identifizierung weniger Defekte
‐ Autor kann die Walkthrough ‐ Sitzung dominieren und die Gutachter blenden.
‐ Überarbeitung des Prüfobjektes liegt in dem Ermessen des Autors. Sie wird nicht
nachgeprüft.
69
Schreibtischtest
Entspricht einer Einmanninspektion/Walkthrough

Probleme:
‐ relativ unproduktiv, weil er ein vollständig undisziplinierter Prozess ist
‐ es ist nicht effektiv sein eigenes Programm zu testen
Eine Sitzung fördert ein gesundes Konkurrenzverhalten. Dieser Anreiz fehlt bei einem
Schreibtischtest.
70
Dynamische Testverfahren
Literatur:
1. Grundlagen
Testen ist der Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden. (Myers, 1987)
Vollständiger Test?
A, B sind ganze Zahlen, mit 16 Bit repräsentiert
Anzahl möglicher Eingaben: 216 * 216 = 232

Ein vollständiger Test erfordert über 4 Milliarden Testfälle.
‐ Vollständiges Testen ist in den meisten Fällen nicht möglich!

‐ Systematisches, intensives Testen erhöht die Wahrscheinlichkeit, dass sich ein
Programm fehlerfrei verhält.
‐ Korrektheit eines Programms kann durch Testen (außer in trivialen Fällen) nicht
bewiesen werden.
‐ Testen setzt voraus, dass die Sollantworten bekannt sind (Test gegen Spezifikation
oder gegen vorhandene Testergebnisse (Regressionstest) )
‐ Tests müssen geplant und dokumentiert werden, da sie ansonsten nicht
nachvollziehbar sind.
Die Software‐Komponente / das Programm, das getestet werden soll, wird als Prüfling, Testling oder
Testobjekt bezeichnet.
Testende Verfahren werden unterschieden in
‐ dynamische Verfahren
‐ das übersetzte, ausführbare Programm wird mit konkreten Eingabewerten
versehen und ausgeführt.
‐ das Programm kann in der realen Umgebung getestet werden
‐ es handelt sich um Stichprobenverfahren; die Korrektheit des getesteten
Programms wird nicht bewiesen.
‐ statische Verfahren
‐ Systemkomponente wird nicht ausgeführt, Quellcode wird analysiert (siehe
Inspektionen u. Walkthroughs)
Testfall: Satz von Testdaten, der die vollständige Ausführung des zu testenden Programms
bewirkt.
Testdatum: Eingabewert, der einem Eingabeparameter/‐ variable des zu testenden Programms
mit einem Datum im Rahmen eines Testfalls versorgt.
71
2. Testablauf
Testplanung
‐ Erstellung eines Testplans mit z.B.
‐ Auswahl der Prüflinge
‐ Festlegung der zu testenden Merkmale (Funktionalität, Lesbarkeit, etc.)
‐ Festlegung der Testziele u. Kriterien für Erfolg, Misserfolg, Abbruch, etc.
‐ Festlegung von Dokumentationsrichtlinien
Testentwurf
‐ Entwicklung einer Teststrategie
‐ Auswahl/Kombination von Testverfahren
‐ Konkretisierung der Testziele
‐ Entwurf der Testumgebung
Testfallermittlung
‐ Bestimmung von Testfällen für jeden Prüfling gem. der Testentwurfsspezifikation
‐ Automatische Erzeugung von Testdaten oder manuelle Ableitung der Testdaten
‐ Spezifikation wann ein Testfall erfolgreich war.
Testdurchführung
‐ Einrichtung der Testumgebung
‐ Tests gemäß ihrer Spezifikation ausführen
‐ Dokumentation der Ergebnisse im Testprotokoll
‐ Aufgedeckte Fehler, Probleme, Besonderheiten werden im Testvorfallbericht
festgehalten.
‐ Prüfling während des Tests nicht verändern.
Testauswertung
‐ Analyse und Verdichtung der Testergebnisse
Fehlerbehebung (nicht Bestandteil des Tests)
‐ Analyse der festgestellten Fehler
‐ Fehlerursachen (Defekte) bestimmen (Debugging)
‐ Fehler beheben
‐
3. Testfälle
‐ Bestimmung der Testfälle ist eine zentrale Aufgabe des Testens
‐ Ziel:
Mit einer kleinen Auswahl an Testfällen möglichst viele Fehler finden.
4. Strukturorientierte Testverfahren
Testfälle werden so ausgewählt, dass der Kontrollfluss oder der Datenfluss im Programm überprüft
wird.
Andere Bezeichnungen: White‐Box Verfahren, Glass‐Box Verfahren
72
Kontrollflussorientierte Testverfahren
Testziel:
Strukturelemente wie Anweisungen, Zweige und Bedingungen werden benutzt, um Testziele
zu definieren.
Ziele / gebräuchliche Testüberdeckungen:
‐ Anweisungsüberdeckungstest
‐ Zweigüberdeckungstest
‐ Pfadüberdeckungstest
Kontrollflussgraph
Kontrollstrukturen dienen dazu den Ablauf eines Algorithmus zu steuern (ob, wie oft eine
Anweisung ausgeführt wird) Beschreibung: PAP oder Kontrollflussgraphen
Ziel: Verdeutlichung des Kontrollflusses
Kontrollflussgraph:
‐ gerichteter Graph
‐ es gibt einen ausgezeichneten Startknoten und einen ausgezeichneten Endknoten.
‐ Knoten stellen die ausführbaren Anweisungen dar.
‐ Gerichtete Kante von einem Knoten i zu einem Knoten j beschreibt einen möglichen
Kontrollfluss vom Knoten i zum Knoten j.
Beispiel (Myers 1987)
...
var A; B, X:integer;
begin
...
if ( A > 1) and (B = 0) then
X := X div A;
if (A = 2) or (X > 1) then
X := X + 1;
...
end.
Kontrollflussgraph zum Beispiel
73
Anweisungsüberdeckungstest
Testziel:
Mindestens einmalige Ausführung aller Anweisungen des zu testenden Programms. (Jeder
Knoten einmal)
Metrik:
Anzahl der ausgeführten Anweisungen

Canweisung=
Gesamtzahl der vorhandenen Anweisungen
Eigenschaften:
‐ Bei 100%Überdeckung: Prüfling enthält keine Anweisungen die nicht ausgeführt
werden.
‐ Nicht ausführbarer Code kann gefunden werden
‐ Keine Berücksichtigung von Kontrollstrukturen noch von Datenabhängigkeiten
‐ Jede Anweisung wird gleich gewichtet.
‐ Als eigenständiges Testverfahren nicht geeignet.
‐ Fehleridentifizierungsquote (stat.): 18%, Girgis, Woodwar 86
Test: A=2, B= 0, X=3
(A <> 2) statt (X >1) wird nicht entdeckt.
74
Zweigüberdeckungstest
Testziel:
Ausführung aller Zweige des zu testenden Programms (Durchlaufen aller Kanten im
Kontrollflussgraphen).
Metrik:
Anzahl der ausgeführten Zweige

CZweig=
Gesamtzahl der vorhandenen Zweige
Eigenschaften (minimale Testkriterium)

‐ 100%Überdeckung: Es gibt keinen Zweig, der nicht ausgeführt wird.
‐ Nicht ausführbare Zweige können gefunden werden.
‐ Kombination von Zweigen noch komplexe Bedingungen werden getestet.
‐ Schleifen werden nicht ausreichend getestet (nur einmal durchlaufen)
‐ Oft durchlaufene Programmteile können erkannt und gezielt optimiert werden.
‐ Fehleridentifikationsquote (stat.): 34%, Girgis, Woodard 86
Test 1: A=3, B=0, X=3

Test 2: A=2, B=1, X=1
Sollte X<1 statt X > 1 geprüft werden, wird der Fehler nicht entdeckt!
Prüfen der einzelnen Bedingungen besser als der Entscheidungen
C ‐ Programm:
x = 1;
if ( x >= 1 )
x := x + 1;
75
Fehler wird entdeckt bei Zweigüberdeckung, aber nicht bei Anweisungsüberdeckung.
76
Pfadüberdeckungstest
Testziel:
Ausführung aller unterschiedlichen Pfade eines Programms
Eigenschaften:
‐ Pfadanzahl wächst bei Wiederholungsanweisungen explosiv. Jede Wiederholung
erzeugt mindestens einen neuen Pfad durch Hinzufügen des im Schleifenkörpers
vorhandenen Subpfades.
‐ Pfade können sich gegeneinander ausschließen. Wann ist der Test vollständig?
‐ Mächtigste kontrollflussorientierte Testverfahren
‐ Besitzt die höchste Erfolgsquote
‐ Geringe praktische Bedeutung wegen der eingeschränkten Durchführbarkeit
Test 1: A=3,B= 0,X=3

Test 2: A=2,B=1, X=1
Test 3: A=3, B=0, X=0
Test 4: A=3,B=1,X=0
C – Programm
#define MAXZEILENLAENGE 80
for (i=0; i < MAXZEILENLAENGE; i++)
if (zeichen[i] == ‘ ‘)
anzahlleer = anzahlleer + 1;
Das Programmfragment enthält 280 Pfade.
77
Bedingungsüberdeckungstestverfahren
Bestehen die Entscheidungen in einem Programm aus
mehreren Bedingungen, dann:
Zweigüberdeckungstest nicht ausreichend
Verbesserung:
a) Einfache Bedingungsüberdeckung
alle (atomaren) Bedingungen müssen einmal true und false sein.
Achtung: überdeckt nicht die Anweisungsüberdeckung und Zweigüberdeckung
b) Mehrfachbedingungsüberdeckung
alle Variationen der (atomaren) Bedingungen einer Entscheidung sollen gebildet werden.
Achtung: Nicht alle Variationen sind möglich!!
c) Minimale Mehrfachbedingungsüberdeckung
Jede Bedingung, ob atomar oder nicht (Entscheidung) muss einmal true und einmal false
sein.
Vorteil gegenüber Zweigüberdeckungstest:
‐ Überdeckung des Zweigüberdeckungstest
‐ Entdeckung von invarianten Bedingungen
‐ Ausführung von Zweigen mit sinnvollen Testdaten
78
10. Übung
Aufgabe 1
Betrachten Sie das folgende Programmfragment:
#define MAXZEILENLAENGE 80
AnzahlLeerzeichen = 0;
for (i=0; i < MAXZEILENLAENGE; i++)
if ( zeichen[i] == ’ ’ )
AnzahlLeerzeichen++;
a) Zeichnen Sie den Kontrollflussgraphen zu obigem Programm.
79
b) Bestimmen Sie die Pfadanzahl im Kontrollgraphen!

Pfadanzahl:
280 Pfade, da man bei jedem Schleifendurchlauf 2 Möglichkeiten (Leerzeichen oder Zeichen)
hat und die Schleife 80 Mal durchlaufen wird.
Aufgabe 2
Gegeben ist da folgende Programm:
float wurzel (float Zahl)
{
float Wert = 0;
if ( Zahl > 0 )
{
Wert = 2;
while (abs(Wert * Wert – Zahl) > 0.01 )
{
Wert = Wert – ((Wert * Wert – Zahl) / (2 * Wert));
}
}
return Wert;
}
Es approximiert für nicht negative Eingabewerte die Quadratwurzel, die als Funktionswert
zurückgeliefert wird. Werden negative Werte angegeben, so wird als Ergebnis 0
zurückgeliefert.
a) Geben Sie zu dem Programm den Kontrollflussgraphen an.
80
ns
n1 float Wert = 0;
n2 if ( Zahl > 0 )
n3 Wert = 2;
n4 while (abs(Wert * Wert – Zahl) > 0.01 )
n5 Wert = Wert – ((Wert * Wert – Zahl) / (2 * Wert));
n6 return Wert;
nE
b) Erstellen Sie Testfälle für

‐ den Anweisungsüberdeckungstest und
‐ den Zweigüberdeckungstest.
Anweisungsüberdeckungstest:
Testfall 1: Zahl 16
Sollantwort:
1. |Ergebnis2‐16|≤0,01
↑Wert
2. Ergebnis > 0
Zweigüberdeckungstest:
Test 1: s.o.
Test 2: Zahl 0
Sollantwort:
Ergebnis: 0
81
Aufgabe 3
Gegeben ist das folgende Programm:
void main ( void )

{
int a, b;
float x;
printf(“Geben Sie bitte zwei ganze Zahlen ein:\n“);

scanf(“%d %d“);
x = a – b;
if ( a > 1 && b == 0 )
x = x/2;
if ( a == 2 || x > 1 )
x+= 1;
printf(“Ergebnis:%f“, x);
return;
}
Erstellen Sie einen Bedingungstest so dass
a) die einfache Bedingungsüberdeckung erfüllt ist.
Entscheidung 1 Entscheidung 2
a>1 b=0 a=2 x>1
a=2; b=0 T T T F
a=0; b=‐2 F F F T
b) die Mehrfachbedingungsüberdeckung erfüllt ist.
Entscheidung 1 Entscheidung 2
a>1 b=0 a=2 x>1
a=2; b=0 T T T F
a=0; b=‐2 F F F T
a=2; b=‐1 T F T T
a=8; b=0 T T F T
c) die minimale Mehrfachbedingungsüberdeckung erfüllt ist.
Entscheidung 1 Entscheidung 2 Entscheidung 1 Entscheidung 2

a>1 b=0 a=2 x>1
a=2; b=0 T T T F T T
a=0; b=‐2 F F F T F T
a=0; b=0 F T F F F F
82
Beispiel (Spillner/ Linz)

double calculate‐price (double baseprice, double special price,
double extraprice, int extras, double discount);
Spezifikation:
Die Funktion soll den Preis für ein Fahrzeug bestimmen:
‐ Ausgegangen wird vom Grundpreis (baseprice) abzüglich des Händlerrabatts
(discount)
‐ Sondermodellaufschlag (specialprice) und Preis für die weitere Zusatzausstattung
(extraprice) sind zu addieren
‐ Werden drei oder mehr Zusatzausstattungen (nicht im gewählten Sondermodell
enthalten) ausgewählt (extras), erfolgt nur auf diese Ausstattungsmerkmale eine
Rabattierung von 10%. Bei fünf oder mehr Zusatzausstattungen erhöht sich die
Rabattierung au f15%.
‐ Der Händlerrabatt bezieht sich auf den Grundpreis und die Zubehörteile. Der
Zubehörpreis ist nur auf die Zubehörteile anzurechnen. Beide Rabatte können
nicht gleichzeitig angerechnet werden. Berücksichtigt wird der größere von den
beiden Rabatten.
83
Double calculate‐price (double baseprice, double specialprice, double extraprice, int extras, double
discount)
{ double addon_discount;
double result;
if (extras >= 5)
addon_discount = 15;
else if (extras >= 3)
addon_discount = 10
else addon_discount = 0;
if (discount >= addon_discount)
addon_disclunt = discount;
result = baseprice * ((100 – discount)/100)
specialprice + extraprice * (100 – addon_discount)/100;
return result;
}
baseprice Extraprice
Extras < 3 Discount Discount
Extras >=3, discount Discount 10%
Extras < 5 < 10%
Extras < 5 discount Discount Discount
> 5 10%
Extras >=5 discount Discount 15%
< 5 15%
Extras <discount Discount discount
> 15%
Testfall bestimmung über Ayuivalenzklassenbildung

1. Definitionsbereiche bestimmen
Parameter Äquivalenzklasse
baseprice gÄK11 [ MIN_DOUBLE,… MAX_DOUBLE]
uÄK12NaN (not a number)
specialprice gÄK21 [ MIN_DOUBLE,… MAX_DOUBLE]
extraprice gÄK31 [ MIN_DOUBLE,… MAX_DOUBLE]
extras gÄK41 [ MIN_INT,… MAX_INT]
discount gÄK51 [ MIN_DOUBLE,… MAX_DOUBLE]
Annahme: Programm zeigt auf die Eingabe fehlerhafter Werte immer das gleiche Verhalten.
84
2. Äquivalenzklassen verfeinern basierend auf der Spezifikation

‐ Parameter 1,2,3 stehen für Preise.Preise sind nicht negativ. Die Spezifikation legt
keine Parameter fest.
‐ Parameter 4 (extras) legt die Anzahl der Zusatzteile fest. Der Parameter sollte
daher größergleich 0 sein. Es wird keine Obergrenze festgelegt.
‐ discont steht für einen Rabatt. Er wird prozentual ausgegeben. D.h. der Wert
sollte zwischen 0 und 100 liegen
(Für 0 ≤ extras < 3, Zubehörrabatt: 0%
Für 3 ≤ extras < 5, Zubehörrabatt: 10%
Für 5 ≤ extras , Zubehörrabatt: 15%)
Parameter Äquivalenzklasse Repräsentat
baseprice gÄK11 [0,… MAX_DOUBLE] 20.000,00
uÄK12 [MIN_DOUBLE,…0[ ‐1,00
uÄK13 NaN „abc“
specialprice gÄK21 [0,… MAX_DOUBLE] 3.450,00
extraprice gÄK31 [0,… MAX_DOUBLE] 6.000,00
extras gÄK41 [0,… 2] 1
gÄK42 [3,4] 3
gÄK43 [5,…, MAX_INT] 20
uÄK44 [MIN_INT,…0[ ‐1
discount gÄK51 [0,…100] 10,00
uÄK53 [100,…, MAX_DOUBLE] 101,00
uÄK54 Nan „abc“
3. Repräsentanten festlegen (abgeschlossen)

4. Testfall festlegen
Es werden „gültige“ Testfälle und „ungültige“ Testfälle festgelegt.
Testfall baceprice specialprice extraprice extras discount result(Soll)

1 20.000,00 3450,00 6.000,00 1,00 10,00 27.450,00
26.850,00
2 20.000,00 3450,00 6.000,00 3 10,00 26.850,00
3 20.000,00 3450,00 6.000,00 20 10,00 26.550,00
4 ‐1,00 3450,00 6.000,00 1,00 10,00 NOT_VALID
5 „abc“ 3450,00 6.000,00 1,00 10,00 NOT_VALID
6 20.000,00 ‐1,00 6.000,00 1,00 10,00 NOT_VALID
7 20.000,00 „abc“ 6.000,00 1,00 10,00 NOT_VALID
8 20.000,00 3450,00 ‐1,00 1,00 10,00 NOT_VALID
9 20.000,00 3450,00 „abc“ 1,00 10,00 NOT_VALID
10 20.000,00 3450,00 6.000,00 ‐1,00 10,00 NOT_VALID
11 20.000,00 3450,00 6.000,00 „abc“ 10,00 NOT_VALID
12 20.000,00 3450,00 6.000,00 1,00 ‐1,00 NOT_VALID
13 20.000,00 3450,00 6.000,00 1,00 101,00 NOT_VALID
14 20.000,00 3450,00 6.000,00 1,00 „abc“ NOT_VALID
NOT_VALID entspricht dem spezifiziertem Fehlercode
85
1. Mensch‐ Computer‐Interaktion
bzw. Software‐Ergonomie
HCI= Human Computer Interaktion
Interaktive Systeme
Kombination von Hardware‐ und Softwarekomponenten die Eingabe von einem Benutzer
erwarten und Ausgaben an einen Benutzer übermitteln, um ihn bei seinen Arbeitsaufgaben
zu unterstützen.
z.B. ‐ Notebook mit MS‐Office zur Erledigung von Bürotätigkeiten
‐ Handy
‐ Kaffeeautomat
‐ Navi
2. Grundsätze der Dialoggestaltung
Norm ISO 9241‐110

Ergonomie der Mensch‐System‐Interaktion
Grundsätze zur Dialoggestaltung
Die sieben folgenden Grundsätze der Dialoggestaltung (umgangssprachlich auch "Dialogprinzipien"

genannt)
‐ Aufgabenangemessenheit;
Ein Dialog ist aufgabenangemessen, wenn er den Benutzer unterstützt, seine Arbeitsaufgabe
effektiv und effizient zu erledigen.
Beispiel: Vorgabe von Standardwerten bei Eingabefeldern, die von der Arbeitsaufgabe her
sinnvoll sind.
‐ Selbstbeschreibungsfähigkeit;
Ein Dialog ist in dem Maße selbstbeschreibungsfähig, in dem für den Benutzer zu jeder Zeit
offensichtlich ist, in welchem Dialog, an welcher Stelle im Dialog sie sich befinden, welche
Handlungen unternommen werden können und wie diese ausgeführt werden können.
Beispiel: Anzeige von Zustandsänderungen des Systems: Wird eine Eingabe erwartet oder ein
Kommando ausgeführt?
‐ Erwartungskonformität;
Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie
seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist.
Beispiel: Verschiedene Nutzungsarten (je nach Erfahrungstand des Benutzers): Aufruf von
Operationen über Transaktionscodes, Menüführung oder direkte Manipulation per Maus.
‐ Lernförderlichkeit;
Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen des Dialogsystems
unterstützt und anleitet.
Beispiel: Anlehnung an Vorgänge, Bilder, Begriffe aus dem Alltag oder dem
Anwendungsgebiet des Dialogsystems
86
‐ Steuerbarkeit;
Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie
seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist.
Beispiel: Verschiedene Nutzungsarten (je nach Erfahrungstand des Benutzers): Aufruf von
Operationen über Transaktionscodes, Menüführung oder direkte Manipulation per Maus.
‐ Fehlertoleranz;
Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar
fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens
des Benutzers erreicht werden kann.
Beispiel: Kein undefinierter Systemzustand oder Systemzusammenbruch nach fehlerhaften

Eingaben
‐ Individualisierbarkeit
Ein Dialog ist individualisierbar, wenn das Dialogsystem Anpassungen an die Erfordernisse
der Arbeitsaufgabe sowie an die individuellen Fähigkeiten und Vorlieben des Benutzers
zulässt.
Beispiel: Abschaltbare bzw. erweiterbare Kommandos und Menüs (definierbare Iconleisten)
87
Themenpunkte
1. Grundsätze für den Entwurf von MCI‐(Mensch‐Computer‐Interaktion) Systemen
2. Richtlinien für den Entwurf von Menüs und Formularen
3. Usability‐Labore und Tests für die Evaluation
Grundsätze für den Entwurf von MCI ‐ Systemen

1. Grundsatz 1: Erkennung der Komplexität
2. Grundsatz 2: Regeln zum Entwurf von Dialogen
3. Grundsatz 3: Fehlervermeidung
Grundsatz 1: Erkennung der Komplexität

Für den Entwurf von Benutzerschnittstellen ist folgendes zu beachten:
a) Benutzerprofile (Benutzeranalyse)
Î Benutzeranalyse:
o Ziel: Know the user
Vorstellung des Benutzers <‐>(stimmt das überein? Reale Benutzer
Benutzeranalyse sollte insbesondere folgende Fragen beantworten:
1. Welche Aufgabenbereiche haben die Benutzer?
2. Welche Sichten und Zugriffsrechte auf Informationen brauchen die Benutzer?
3. Welchen Wissenshintergrund haben die Benutzer?
4. Welchen anwendungsbezogenen Hintergrund bringen die Benutzer mit?
5. Welche Erfahrungen haben die Benutzer zu bestimmten zu bestimmten
Anwendungssystemen?
6. Mit welchen Arbeitsmitteln sind die Benutzer vertraut?
7. Welche Funktionalität, welche Eigenschaften und welches Verhalten erwarten die Benutzer
vom System?
Weitere Kriterien: Alter, Geschlecht, Behinderung,…
Î Benutzerprofil
Beispiel: Def. Der Benutzerprofile über Erfahrungen mit dem Computersystem
• Novizen (erstmaliger Benutzer, Anfänger)
‐ Kennt das Computersystem nicht
‐ Evtl. fehlende Kenntnisse über Aufgaben und Lösungswege
‐ Evtl. Angst vor dem System
Lösung: ‐ Einschränkung des Systems auf wenige Funktionen, die mit Erfolg
ausgeführt werden können ‐> Vertrauen
‐ aussagekräftige Instruktionen
‐ aussagekräftige und konstruktive Fehlermeldungen
‐ informativer Feedback
• Fortgeschrittene
‐ Kennt das System und das Interaktionskonzept
‐ Haben das System aber noch nicht über einen längeren Zeitraum intensiv genutzt
‐ Haben beispielsweise noch Probleme beim Auffinden von Menüpunkten oder
Funktionen
Lösung: ‐ strukturierte Menüs
‐ konsistente Terminologie
‐ konsistente Aufgabenfolge
‐ Undo‐Funktionalität
‐> ermutigt den Benutzer die Systemfunktionalität zu erforschen
‐ Online help, manuals, etc.
88
• Experten
‐ beherrscht Aufgaben und Benutzungsschnittstelle
o Umfangreiche Erfahrung in der Arbeit mit dem Computersystem liegen vor
‐ Setzt die zu Verfügung stehenden Funktionen rasch und zielgerichtet um
‐ Kurzes Feedback
‐ Kommandos, Abkürzungen,…
‐ Makros,…
‐ Kurze Antwortzeiten
Wichtig: ‐Feedback sollte auf den Benutzer und sein Profil zugeschnitten sein
‐ Benutzer können sich vom Anfänger zum Experten entwickeln
b) Aufgabenprofile (Aufgabenanalyse)
• Beispiel: Frequenz, Zuordnung, etc.
Grundsatz 1: Erkennung der Komplexität (2)
c) Interaktionsformen
• direkte Manipulation
• Menü
• Formulare
• Kommandosprachen
• natürliche Sprachen
Wichtig: Die Vielzahl an möglichen Ausprägungen von Benutzerprofilen, Aufgabenprofilen und
Interaktionsformen lassen den Entwurf von MCI ‐ Systemen zu einer sehr komplexen Aufgabe
werden.
Grundsatz 2: Regeln zum Entwurf von Dialogen
Die folgenden „ Acht goldene Regeln“ wurden von Shneidermann 1992 formuliert und sind bei
Entwicklung von interaktiven System generell anwendbar:
1. Versuche Konsistenz zu erreichen
Terminologie, Menü, Hilfefenster, Farbe, Layout, Groß‐/Kleinschreibung, Schriftgröße (Fonts)
2. Unterstütze erfahrene Benutzer
Je häufiger ein System benutzt wird, desto größer ist der Wunsch Aktionen schnell auszuführen. Dies
kann durch Abkürzungen, Funktionstasten, versteckte Kommandos, und Makros erreicht werden.
3. Biete informatives Feedback an
Jede Aktion sollte zu einer einer informativen Systemreaktion führen. Die Reaktion sollte von der
Wichtigkeit der Aktion abhängen.
4. Entwerfe abgeschlossene Dialoge
Dialoge bestehen in der Regel aus einer Folge von Aktionen. Der Beginn und Ende eines Dialoges
sollte klar erkennbar sein. Das Ende kann zum Beispiel durch eine Systemreaktion kenntlich gemacht
werden.
„Bestellung mit Nr. 4500001674 ist angelegt“
5. Biete eine einfache Fehlerbehandlung
Es sollte nicht möglich sein schwerwiegende Fehler zu begehen.
Beispiele: ( a ) In numerischen Feldern sollte es nicht möglich sein Buchstaben einzugeben.
( b ) Bei fehlerhaften Kommandos sollte es möglich sein, nur den fehlerhaften Teil zu ersetzen.
( c ) Bei einem Fehler sollte das System darüber informieren, wie der Fehler zu beheben ist.
6. Biete eine Undo ‐ Funktionalität für alle Aktionen
Es sollte möglich sein eine Aktion rückgängig zu machen. Dadurch verliert der Benutzer die Angst vor
Fehlern und wird ermutigt neue Aktionen auszuführen.
89
7. Unterstütze einen benutzergesteuerten Dialog

Erfahrene Benutzer wollen das Gefühl haben, dass sie den Dialog steuern und beherrschen.
Unerwartete Systemantworten, Schwierigkeiten bei der Informationsbeschaffung und bei der
Ausführung von Funktionen führen zu Angst.
Der Benutzer sollte das Gefühl des Initiators und nicht des Beantworters von Aktionen sein.
8. Reduziere die Belastung des Kurzzeitgedächtnisses
einfache Dialoge, keine Dialogseiten, die über eine Bildschirmseite hinausgehen, Hilfemöglichkeiten
für Kommandos, Icons, usw.
Grundsatz 3: Fehlervermeidung
Ergebnis einer Analyse der Arbeitweise von Experten:
• Gegenstand der Analyse waren Textverarbeitungsprogramme und Tabellenkalkulationen
• Ergebnis: Bei 31% der zugeteilten Aufgaben wurden Fehler gemacht oder es wurden ineffiziente
Lösungsstrategien ausgewählt.
Damit: Fehler werden häufiger gemacht als gewöhnlich angenommen!!! Und führen zu einer
geringeren Produktivität Techniken um sichere Aktionen zu unterstützen:
• Einhaltung der Syntax
• Vollständige Aufgabensequenzen
• Korrektur von Kommandos
Einhaltung der Syntax
Ein häufiges Problem ist die Einhaltung der Klammerung von Ausdrücken:
Beispiele:
• Suchanfrage in in einem Bibliothekssystem: Computers and ( Psychology or Sociology)
Wenn eine Klammer vergessen wurde, wird in der Regel eine Fehlermeldung erzeugt: SYNTAX
ERROR, UNMATCHED LEFT PARANTHESIS
• HTML
<B> This is boldface </B>
Wenn das rechte </B> kommt es zu einem Fehler
Fehlervermeidung: Entwicklung von speziellen Editoren, die bei Eingabe eines öffnenden
Klammerungszeichen das schließende Klammerungszeichen ergänzen und den Cursor dazwischen
plazieren.
Mindestens: Hinweis, daß ein schließendes Klammerungszeichen erwartet wird.
Vollständige Aufgabensequenzen
Manchmal besteht eine Aufgabe aus mehreren Aktionen, die hintereinander ausgeführt werden
müssen. Dabei besteht die Gefahr, daß eine Aktion vergessen wird und die Aufgabe unvollständig
abgearbeitet bleibt.
Fehlervermeidung:
• System sollte nach Abarbeitung einer Aktion automatisch die Folgeaktion zur
Bearbeitung vorschlagen.
Beispiel:
Betriebswirtschaftliche Anwendungssoftware
Nach Anlegen einer Bestellung wird die Bestellung normalerweise gedruckt
oder zum Drucken freigegeben. Das System könnte nach dem Sichern die
Transaktion zum Freigeben vorschlagen.
Korrektur von Kommandos
Bei der Verwendung von Kommandosprachen werden oft Kommandos
unvollständig eingegeben.
Die Folge sind Fehlermeldungen der Art: WHAT?, UNRECOGNIZED
COMMAND, SYNTAX ERROR, BAD FILE NAME oder ILLEGAL
COMMAND
Fehlervermeidung:
• Automatische Ergänzung von Kommandonamen
Bestätigung durch Drücken eines Leerzeichens
90
Vorteil: Weniger Eingaben, weniger Fehler, etc.

• Direkte Manipulation, wenn möglich
Gestaltung von Menüs
Bei der Gestaltung von Menüs sind folgende Punkte von Interesse:
• Titel
• Bezeichnung und Anordnung der Auswahlpunkte (Menüpunkte)
• Graphische Darstellung
Titel von Menüs
• Einzelmenü: Titel soll eine aussagekräftige Beschreibung sein.
• Lineare Menüfolge: Titel soll eine aussagekräftige Beschreibung sein.
Zusätzlich sollte die Position eines Menüs innerhalb der Folge sichtbar sein.
• Baummenü: Die Menüpunkte des Hauptmenüs sollten mit den Titeln der
Untermenüs übereinstimmen.
Î Tiefe oder breite Realisierung
Empfehlung:
Breite einer Ebene < 4‐8 Menüpunkte
Tiefe < 3‐4 Ebenen
‐ Erweiterung: azyklische Menünetzwerke
‐ Zyklische Menünetzwerke
Konsistente Gestaltung: Titel sollte immer an der gleichen Position erscheinen.

Cranda, 1983: Die Nachdenkzeit des Benutzers verdoppelt sich, wenn die Positionierung der
Information uneinheitlich ist.
Bezeichnung der Menüpunkte
Die Bezeichnung der Menüpunkte stellt sich in der Praxis als sehr schwierig heraus. Sie muss
empirisch durch Akzeptanztests oder Benutzer‐Performance‐
Monitoring ermittelt werden.
Richtlinien:
• Vertraute und konsistente Terminologie
• Trennung der einzelnen Bezeichnungen
• Konsistente und kurze Beschreibungen
Tiere ist besser als Information über Tiere
• Schlüsselwörter nach links
Size of type besser als Set the size type
Reihenfolge der Auswahlpunkte
‐ Natürliche Reihenfolge
o Chronologische Kriterien
o Numerische Kriterien
o Physikalische Kriterien
91
‐ Keine natürliche Reihenfolge

o Alphabetisch
o Auswahlhäufigkeit
o Gruppierung nach logisch thematische Gesichtspunkten
Menü‐Layout
Entwickler muss die Konsistenz der folgenden Punkte sicherstellen:
• Titel
(linksbündig)
• Platzierung der Auswahlpunkte
(linksbündig, Trennlinien)
• Instruktionen
sollen für alle Menüs gleich sein
• (Funktionstasten, Hilfe, usw.)
• Fehlermeldungen
immer am gleichen Platz u. gleiche Struktur
• Status‐Reports
Wo befindet man sich im Menü?
Name des Menüs (Makros)
Richtlinien für die Formulargestaltung
(B. Shneidermann, 1998)
1. Programm nach eigenen Ideen entwickeln unter Berücksichtigung der Richtlinien, Regeln,
Style Guides, …
• Sinnvoller Titel
• Leicht zu verstehende Instruktionen
• Logische Gruppierung und Reihenfolge der Felder
• Ansprechendes Layout
• Allgemein verständliche Bezeichnungen
• Konsistente Terminologie und Abkürzungen
• Klare Abgrenzung der Felder
• Gewohnte Cursorbewegungen (TAB oder Cursortasten)
• Fehlerbehebung für einzelne Zeichen oder ganze Felder
• Fehlermeldungen bei nicht akzeptierten Werten
• Kennzeichnung von optionalen Feldern
• Erläuterungen zu den einzelnen Feldern
• Feedback nach vollständiger Bearbeitung
Usability‐Labore und Tests
Seit Anfang der 80‘er Jahre wird die Benutzerfreundlichkeit u. Gebrauchstauglichkeit (=Usability)
mehr und mehr zum Gegenstands von Tests während und nach Abschluss der Entwicklung.
Problem: (bis heute)
Usability‐Tests werden in vielen Software‐Unternehmen vom Management als auch von den
Entwicklungsabteilungen abgetan als
• nette Idee oder
• Nicht durchführbar wegen Zeitdrucks und beschränkten Ressourcen.
Ziel:
Usability‐Tests sollten frühzeitig bei der Projektplanung als Meilenstein berücksichtigt werden:
• Beschleunigung der Entwicklungsarbeiten
• Kostenersparnis durch Reduzierung nachträglicher Änderungen
92
Aufbau von Usability‐Laboren

Personal:
• Mehrere Mitarbeiter mit Erfahrung im Testen und Entwicklung von Benutzerschnittstellen.
• Mitarbeiter betreut durchschnittlich 10 – 15 Projekte pro Jahr
Ausstattung:
• Spezialsoftware für Logging, Video‐Aufzeichnung, etc...
Ziel:
a) Akademische Tests
– Untersuchung von Theorien
– Validierung von Modellen
b) Praktische Tests
– Verbesserung von in der Entwicklung befindlichen Benutzerschnittstellen
– Prüfung von Benutzerschnittstellen hinsichtlich Usability
Testablauf
• Erarbeitung eines Testplans mit

– Projektmanagement
– Entwickler
– Spezialisten des Usability‐Labors
Festlegung von Terminen und Budget
• Teilnahme der Usability‐Spezialisten an den Design‐Reviews
• 2‐6 Wochen vor Beginn des Tests muss folgendes vorliegen:
– Testplan
– Aufgaben
– Fragebögen (Bewertung der persönlichen Zufriedenheit mit der
Benutzerschnittstelle)
– Anzahl der Teilnehmer
– Beschreibung der Art der Teilnehmer (EDV‐Erfahrung, Vorbildung etc.)
• Pilottest
erfolgt eine Woche vor dem eigentlichen Test. Mängel können dadurch nochbeseitigt werden.
93
Teilnehmerauswahl und Umgebung

Wissensstand:
– Grundwissen in der Datenverarbeitung
– Erfahrung mit der zu bewältigenden Aufgabe
– Motivation
– Ausbildung
– Kenntnis der Schnittstellen(‐sprache)
Physische Kriterien:
– Sehkraft
– Rechtshänder/Linkshänder
– Alter
– Geschlecht
Umgebung:
– Tageszeit, Wochentag
– Umweltfaktoren (Lärm, Raumtemperatur und Beeinflussung)
Testdurchführung
Informierung der Teilnehmer
• Was müssen die Teilnehmer machen?
• Wie lange?
• Teilnahme muss freiwillig sein.
Beobachtung:
• Probanden sollen laut denken
• Videoaufzeichnungen
• Spezialsoftware: Log‐Dateien mit den Mausbewegungen, Zugriff auf
Hilfedateien, etc.
Test in der realen Umgebung
• Tests sollten wenn möglich mit testunterstützender Software ausgeführt werden
(Ermittlung der Produktivität, Anzahl der Zugriffe auf die Hilfedateien etc.)
• Verteilung von Testversionen an die Anwender
Beispiel: Beta‐Test von Microsofts Windows 95 (400.000 Teilnehmer)
Testauswertung
• Testauswertung sollte durch die Spezialisten des Usability‐Labors und den Entwickler gemeinsam
erfolgen.
• Entwickler erkennen oft schon direkt eventuelle Verbesserungsmöglichkeiten bei Betrachtung der
Videoaufzeichnungen
Teilweise ist die Aussagekraft der Tests begrenzt:
• Normalerweise arbeiten die Probanden zum erstenmal mit dem System währenddes Tests
• Testdauer beträgt in der Regel nur 2 – 4 Stunden
• Es wird in der Regel nur ein Teil der Gesamtfunktionalität getestet.
Problem: Wie schnell werden die Aufgaben nach einer Woche/einem Monat bei regelmäßiger
Anwendung gelöst?
94

1 Was Ist Software Engineering

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

1 Was Ist Software Engineering

Hochgeladen von

Copyright:

Verfügbare Formate

SOFTENG WS 07/08 Dirk Busse

1. Was ist Software – Engineering?

Voraussetzung: Progra I; Progra II; eventuell Java

Î Jetzt: Wie kann man Programme dieser Größenordnung entwickeln?

Wo liegen die Unterschiede?

Ziele: Software – Entwicklungsprozess soll:

Rollenmodell definiert Regeln Methoden u. Werkzeuge

wird ausgeführt von wird verwendet für

Modelle unterscheiden sich hinsichtlich:

Beispiele für Vorgehensmodelle

‐ Phasen werden nacheinander abgearbeitet

‐ Phasenmodell mit Prototypentwicklung

Evolutionäre Software – Entwicklung

Software – Entwicklung ist eine Frage von Entwicklungszyklen (iteratives Vorgehen/Schleife)

Î Inkrementelle Software – Entwicklung

Vorgehensmodelle: RUP (Rational Unified Process)

b) Welche der in der Vorlesung gegebenen Qualitätsmerkmale beeinflussen die

V‐Modelle werden direkt auf das Produkt hin zugeschnitten

3. Analyse und Definition

Klassifizieren von Anforderungen:

Funktionale Anforderungen spezifizieren:

Nicht funktionale Anforderungen spezifizieren:

2. Klassifizieren nach Lebensdauer

Validierung von Anforderungen

Formulieren Sie nicht funktionale Beispielanforderungen zu den Klassen Product

Besprechung des Pflichtenheftes

4. Grundlegende Techniken zu Beschreibung von Anforderungen

Vaterfunktion von B u. C A Kindfunktion von A

Anfragebearbeitung Angebotsbearbeitung Bestellbearbeitung

Anfrage anlegen Angebot anlegen Bestellung anlegen

Anfrage ändern Angebot ändern Bestellung ändern

Anfrage löschen Angebot löschen Bestellung versenden

Anfrage stornieren Angebot vergleichen Bestellung löschen

Anfrage versenden Bestellung stornieren

Beispiel: (De Marco) "()optional"

Entity ‐ Realationship‐ Modell

Pers. Nr. Veranst. Nr.

1+n Kardinalität 1+n

Beschreibung von Abläufen / Algorithmen

Inhalte: 1. Ausgangssituation und Zielsetzung

Am Umwelt‐Campus wurde ein neues E‐Mail‐System (https://webmail.umwelt‐campus.de)

Adressen hinzufügen Erweiterte Suche CSV‐Import

Speichern Suchen Durchsuchen

Übernehmen Abbruch Import

Bestimme Jahre vor

Vorschlag: Anzahl Altersstufen bleibt gleich, 2 Altersstufen werden parametrisiert; AS(1)=30;

Bestimmtes Alter (A)

Bestimme Jahre der Betriebszugehörigkeit (B)

U= MU(1) + B A >= AS(2)

U <= MU(B) U= MU(2) + B U = MU(3) + B

/ U=MAXU Ja nein Ja nein

5. Objektorientierte Analyse und Design mit UML im Überblick

Gegenstände aus der realen Objekte bzw. Klassen

Grundkonzepte Details Î Prog 3

UML = Unified Modeling Language

In unserem Bereich: Inhaber der Firma, Benutzer, Programmierer,

‐ Vorbereiten und Testen von Fragebögen,

b) Welche Techniken zur Ermittlung der Anforderungen werden vorgeschlagen?

Kurzbeschreibung Kurze informelle Beschreibung der Funktion

Eingaben Beschreibung der Eingaben, die verarbeitet werden

Quelle Beschreibung der Herkunft der Eingaben (z.B. Benutzereingaben)

Ausgaben Beschreibung der Ausgaben, die erzeugt werden

Ziel Beschreibung, wo die Ausgaben hingeschrieben werden.