1. Was ist Software Engineering?mediainformatik.de/ftp/homes/guest/Softeng... · 2009. 4. 4. ·...

1

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.

SOFTENG WS 07/08 Dirk Busse

2

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 ‐ 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

Topebene


3

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)

Implementierung

Betrieb

Test

Entwurf

Analyse


4


5

‐ 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

‐ 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

Analyse

Entwurf

Implementierung

Test

Prototypentwicklung

Betrieb / Wartung


6

Evolutionäre Software – Entwicklung Anwendung falls die Anforderungen unsicher, unscharf sind Idee: Prototyp nicht wegwerfen, sondern analysieren und weiterentwickeln bis zum fertigen System Ist neuer Prototyp erforderlich? 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

Validierung

Modifikation der Produktdefinition

Planung &

1. Produktdefinition

Prototyperstellung

Auslieferung Betriebe


7

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.


8

Verbrauchsverhalten: Merkmale von Software, die sich darauf beziehen, wie viele Betriebsmittel bei der Erfüllung ihrer Funktionen benötigt werden und wie lange.


9

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 ‐ Zuverlässigkeit ‐ Benutzbarkeit ‐ Effizienz (Zeitverhalten) ‐ (Änderbarkeit interessiert weniger) Benutzer (IT) ‐ Zuverlässigkeit ‐ Effizienz (Speicher, Zeit) ‐ Änderbarkeit ‐ Übertragbarkeit


10

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.


11

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


12

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)


13

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. )


14

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


15

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.


16

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


17

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. Interpretation: a) A besteht aus B und C b) A ruft B und C auf Beispiel:

A

B C

Kindfunktion von AVaterfunktion von B u. C

Einkaufsabwicklung

Anfragebearbeitung Angebotsbearbeitung Bestellbearbeitung

Anfrage stornieren

Anfrage löschen

Anfrage ändern

Anfrage anlegen

Anfrage versenden

Bestellung löschen

Bestellung versenden

Bestellung ändern

Bestellung anlegen

Angebot vergleichen

Angebot löschen

Angebot ändern

Angebot anlegen

Bestellung stornieren

Bestellung überwachen


18

1 + n

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) 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 + (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:

0‐m

"()optional"

"[]" Auswahl‐möglichkeite

Dozent

Themengebiet

Veranstaltung

Gebietsnummer

Kardinalität

1 + n

Entit‐ tätstypen

Beziehungstypen

Thema

1 + 1

Vorname

Name

Pers. Nr. Veranst. Nr.

Name

SWS

Attribute

bearbeitGehört zu

hält

1 + n 1 + n


19

Beschreibung von Abläufen / Algorithmen a) Programmablaufplan b) Strukturgramme c) Pseudo‐Code (strukturierte Sprache)


20

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,…


21

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. 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 3. für Arbeitnehmerinnen nach Vollendung des 50. Lebensjahres 28 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 3. für Arbeitnehmerinnen nach Vollendung des 50. Lebensjahres bis zu höchstens 33 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.

Abbruch

CSV‐Import

Speichern

Import

Durchsuchen

Erweiterte Suche

Übernehmen

Abbruch

Löschen

Adressen hinzufügen

Adressbuch bearbeiten

Suchen


22

Aufgabe 4

Programmablaufplan (PAP)

ja

nein

nein ja

ja

ja

Start

Bestimme Alter (A)

Bestimme Jahre vor Betriebszugehörigkei

t (B)

A >= 30

Urlaubsanspruch (U)

= 26 + B A >= 50

U <= 29U = 27 + B U = 29

U <= 30U = 30

A

C

C

U = 28 + B

U <= 33

A B

U = 29

U ausgeben

End

ja

nein


23

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)

Ja nein

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

/

U=MAXU

U<=MAXU(2)

Ja nein

U<=MAX(3)

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


24

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 realen oder fiktiven Welt

Log. Ebene Modelle, die eine Software beschreiben

Physische Ebene 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 Welt

Objekte bzw. Klassen

Grundkonzepte Details Prog 3 ‐ Objekte ‐ Klasse ‐ Attribute ‐ Operationen (Methoden, Services) ‐ Beziehungen zwischen Klassen, z.B. Vererbung ‐ Polymorphie (Vielgestaltigkeit)


25

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


26

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,


27

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)


28

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

B2 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!


29

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


30

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


31

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 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. Graphische Darstellung

Akteur

Systemname

QIS: Student, Dozent, Mitarbeiter im Prüfungsamt, Administrator,…


32

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 Graphische Darstellung

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:


33

Beziehungen zwischen Anwendungsfällen Generalisierung bzw. Spezialisierung Idee: Darstellung einer Funktionalität auf höherer Ebene ohne in die Einzelheiten zu gehen Beispiel

Noten bearbeiten

Noten ändernNoten löschenNoten erfassen

Abstrakter Anwengungsfall

Konkrete Anwendungs-

fälle

Enthaltensbeziehung zwischen Anwendungsfällen (include) Idee: Herausziehen gemeinsamer Funktionalität aus Anwendungsfällen und kreieren eines neuen Anwendungsfalls

<<include>>

Erweiterungsbeziehungen zwischen Anwendungsfällen (extent) Idee: Ergänzung zusätzlicher Funktionalität zu einem Anwendungsfall unter bestimmten Bedingungen:


34

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


35

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


36

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: 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

Medium ausleihen


37

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‐‐‐‐


38

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


39

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 ‐Abarbeiten eines Algorithmus: Sortiere ‐ Aufruf von Verhalten, dass als Aktivität modelliert ist 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.

A k tio n s n a m e

A k tiv itä ts n a m eA k tio n


40

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


41

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 2. für Arbeitnehmerinnen nach Vollendung des 30. Lebensjahres 27 Werktage 3. für Arbeitnehmerinnen nach Vollendung des 50. Lebensjahres 28 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 3. für Arbeitnehmerinnen nach Vollendung des 50. Lebensjahres bis zu höchstens 33 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


42

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.


43

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:


44

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 Über Stereotypen können Klassen spezifiziert werden 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)

KlassennameAttribute

Operationen

Klassenname Klassenname Klassenname

Attribute Operationen

<<entity>> Klassenname

Attribute

Operationen

<<controlle>> Klassenname

Attribute

Operationen

Stereotyp Entity‐Klasse Controller‐Klasse


45

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) Operationen Operationsdeklarationen: [Sichtbarkeit]name([Parameterliste]) [:[Rückgabetyp] {Eigenschaftswert}] Parameterliste: kann auch detailliert spezifiziert werden: ‐ Übergaberichtung ‐ Name ‐ Typ ‐ Multiplizität ‐ … Beispiel :

Klassenname

alt1 + alt2:int + p: double = 3,14 ‐ alt3: String [0…*] {read only}

Klassenname

+ op1() ‐op2(in param1/:int = 5):int #op3 (param2:Klasse) . . .


46

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


47

Assoziation

Navigierbarkeit Festlegung, ob eine Assoziation uni‐ oder bidirektional implementiert wird a) unidirektionale Assoziation

Class A Class B*1

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.


48

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:


49

Ü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!


50

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 • Eine Komposition besteht aus


51

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 • Eine Komposition 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.


52

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


53

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


54

Angestellter

Vollzeitkraft Teilzeitkraft

Arbeitszeit

Aushilfskraft Manager Sozialarbeiter

Tätigkeit

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 ‐ …


55

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:


56

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)


57

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.


58

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 Wurzelverzeichnis

Ordner

- Dateianzahl

Datei

- letzter Zurgriff- geändert am

Verknüpfung

- Zielobjekt

- erstellt am- Größe- Art- Name

0...1

* * 1


59

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.


60

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 Graphische Darstellung

‐ 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.


61

Darstellung:

Darstellung:

Spezielle Zustände: Startzustand: ‐ Startpunkt beim Betreten des Zustandsautomaten ‐ 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 ‐ haben keine ausgehende Transitionen ‐ es kann mehrere Endzustände geben

Hinweis: Verlassen eines Zustandsautomaten, der ein Objekt beschreibt, sollt die Lebensdauer des Objekts beenden.


62

Übung 9 Aufgabe 1

Gegeben ist der folgende Auszug aus der Bedienungsleitung einer Digitaluhr:

Erstellen Sie ein Zustandsdiagramm zur Verhaltensbeschreibung dieser Digitaluhr. Antwort:


63


64

Aufgabe 2 Beschreiben Sie das Verhalten von Objekten der Klasse Buch aus Übung 7 / Aufgabe 2 über ein Zustandsdiagramm.


65

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‐ Architektur auf einer hohen Abstraktionsebene {

‐ Paketdiagramme ‐ 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


66

PDF „V09.php“ von FS‐DOMAIN einfügen!!!!!!!!!!! \krieger\ws07\SOFTENG\v09.pdf


67

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)


68

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.


69

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.


70

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.


71

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.


72

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


73

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


74

Anweisungsüberdeckungstest Testziel:

Mindestens einmalige Ausführung aller Anweisungen des zu testenden Programms. (Jeder Knoten einmal)

Metrik:

Anzahl der ausgeführten Anweisungen

Gesamtzahl der vorhandenen AnweisungenCanweisung=

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.


75

Zweigüberdeckungstest Testziel:

Ausführung aller Zweige des zu testenden Programms (Durchlaufen aller Kanten im Kontrollflussgraphen).

Metrik:

Anzahl der ausgeführten Zweige

Gesamtzahl der vorhandenen ZweigeCZweig=

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;


76

Fehler wird entdeckt bei Zweigüberdeckung, aber nicht bei Anweisungsüberdeckung.


77

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.


78

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


79

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.


80

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.


81

ns

n1

n2

n3

n4

nE

n5

n6

float Wert = 0;

if ( Zahl > 0 )

Wert = 2;

while (abs(Wert * Wert – Zahl) > 0.01 )

Wert = Wert – ((Wert * Wert – Zahl) / (2 * Wert));

return Wert;

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


82

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


83

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.


84

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 Extras < 5 < 10%

Discount 10%

Extras < 5 discount > 5 10%

Discount Discount

Extras >=5 discount < 5 15%

Discount 15%

Extras <discount > 15%

Discount discount

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]

uÄK22NaN (not a number) extraprice gÄK31 [ MIN_DOUBLE,… MAX_DOUBLE]

uÄK32NaN (not a number) extras gÄK41 [ MIN_INT,… MAX_INT]

uÄK42NaN (not a number) discount gÄK51 [ MIN_DOUBLE,… MAX_DOUBLE]

uÄK52NaN (not a number)

Annahme: Programm zeigt auf die Eingabe fehlerhafter Werte immer das gleiche Verhalten.


85

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]

uÄK12 [MIN_DOUBLE,…0[ uÄK13 NaN

20.000,00 ‐1,00 „abc“

specialprice gÄK21 [0,… MAX_DOUBLE] uÄK22 [MIN_DOUBLE,…0[ uÄK23 NaN

3.450,00 ‐1,00 „abc“

extraprice gÄK31 [0,… MAX_DOUBLE] uÄK32 [MIN_DOUBLE,…0[ uÄK33 NaN

6.000,00 ‐1,00 „abc“

extras gÄK41 [0,… 2] gÄK42 [3,4] gÄK43 [5,…, MAX_INT] uÄK44 [MIN_INT,…0[ uÄK45 NaN

1 3 20 ‐1 „abc“

discount gÄK51 [0,…100] uÄK52 [MIN_DOUBLE,…0[ uÄK53 [100,…, MAX_DOUBLE] uÄK54 Nan

10,00 ‐1,00 101,00 „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


86

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


87

‐ 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)


88

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.


89

• 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.


90

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


91

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


92

‐ 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


93

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.


94

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?


1. Was ist Software Engineering?mediainformatik.de/ftp/homes/guest/Softeng... · 2009. 4. 4. ·...

Documents

Transcript of 1. Was ist Software Engineering?mediainformatik.de/ftp/homes/guest/Softeng... · 2009. 4. 4. ·...