Softwaretechnik. Arbeitsblätter zur Vorlesung. Lesender: Prof. Dr. I. Philippow. Studiengänge: Ingenieur-Informatik, Wirtschaftsinformatik

Transkript

1 Arbeitsblätter zur Vorlesung Softwaretechnik Lesender: Prof. Dr. I. Philippow Studiengänge: Ingenieur-Informatik, Wirtschaftsinformatik Empfohlen: ab 3. Semester Voraussetzungen: - Kenntnisse zum prozeduralen und objektorientierten Programmieren - Veranstaltung: Algorithmen und Programmierung

2 Bild 2.1. Wasserfallmodell Integration von Qualitätssicherungsmaßnahmen Planung Validierung Lastenheft Anforderungsanalyse Validierung Pflichtenheft Grobentwurf Validierung Fachmodell Feinentwurf Verifizierung Softwarearchitektur und ihre Module Implementierung Modultest Teilprogramme Integration Integrationstest Endprodukt Installation Systemtest laufende Version Betrieb und Wartung Re- Validierung

3 Bild 2.2. Struktur und Sichten im V-Model l Anwendersicht Anwendungsszenarien Abnahmetest Grobentwurf Feinentwurf Architektursicht Testfälle für den Systemtest Testfälle für den Integrationstest Systemtest Anforderungsdefinition Integrationstest Modulimplementierung Implementierungssicht Testfälle für den Modultest Modultest Bild 2.3. Prototyping Vorgehen Problemanalyse/ Systemspezifikation User-Interface- Prototyping Entwurf Architektur- Prototyping Implementierung, Integration

4 Bild 2.4. Spiralenmodell von Boehm * das Spiralenmodell wird in verschiedenen Abwandlungen in der Literatur vorgestellt, z.b. Pomberger/Pree: Integration des make- or- by-aspect

5 Bild 2.5. Unified Process RUP Kruchten, P: The Rational Unified Process. Addison-Wesley 2000 Bild 2.6. XP-Vorgehensmodell requirements User Stories test scenarios Release Planning uncertain/ confident solution release plan new story sytems metaphor Iteration latest version bugs Acceptance Tests customer approval Small Releases Spike Architectural Spike next release

6 Bild 3.1. Beispiel Lastenheft für Getränkeshop 1. Ziel Der Getränkeshop soll befähigt werden, Kundendaten und telefonische Bestellungen on-line zu bearbeiten. 2. Produkteinsatz Das Produkt dient der Verwaltung von Kunden und Bestellungen. Zielgruppe sind die Mitarbeiter des Getränkeshops. 3. Produktfunktionen /LF10/ Erfassen, Ändern und löschen von Kundendaten /LF20/ Erfassen, Ändern und löschen von Produktdaten /LF30/ Abfrage von Kundendaten /LF40/ Erfassen von Bestellungen /LF50/ Ausgabe von Lieferauftrag und Rechnung 4. Produktdaten /LD10/ Kundendaten speichern /LD20/ Produktdaten speichern /LD10/ Bestelldaten speichern 5. Produktleistungen /LL10/ maximale Dauer von /LF30/ und /LF50/ sind 5 sec /LL20/ Es sollen bis zu 200 Warentypen und maximal 1000 Kunden verwaltet werden 6. Qualität Funktionalität gut Zuverlässigkeit mittel Bedienbarkeit sehr gut Effizienz mittel Wartbarkeit gut Portierbarkeit nicht relevant

7 Bild 3.2. Klassifizierung von Function Points Klassifizierung der Eingabedaten: < 2 Datentypen 2 Datentypen > 2 Datentypen < 5 Datenelemente 5-15 Datenelemente > 15 Datenelemente einfach einfach mittel einfach mittel komplex mittel komplex komplex Klassifizierung der Ausgabedaten und Abfragen: < 2 Datentypen 2-3 Datentypen > 3 Datentypen < 6 Datenelemente 6-19 Datenelemente > 19 Datenelemente einfach einfach mittel einfach mittel komplex mittel komplex komplex Klassifizierung Datenbestände und Referenzdaten 1 Datentypen 2-5 Datentypen > 5 Datentypen < 20 Datenelemente Datenelemente > 50 Datenelemente einfach einfach mittel einfach mittel komplex mittel komplex komplex

8 Bild 3.3 Functions-Point-Verfahren, Berechnung der Unadjusted Functions-Points (UFP) Funktionsbereiche Anzahl Bewertung Punkte Eingaben... Einfach x Mittel x Komplex x 6... Ausgaben... Einfach x Mittel x Komplex x 7... Abfragen... Einfach x Mittel x Komplex x 6... Anwenderdateien... Einfach x Mittel x Komplex x Referenzdaten... Einfach x Mittel x Komplex x E1: UFP Bild 3.4 Function-Point-Verfahren, Berechnung der Einflussfaktoren Nr. Einflussfaktoren Max. Punkte Punkte 1. Verflechtung mit anderen Systemen Dezentrale Datenverwaltung Transaktionen (Rate) Schwierige Rechenoperationen Viele Kontrollverfahren Viele Ausnahmen Komplexe Logik Wiederverwendbarkeit Konvertierung des Datenbestands Bedienung 5... E2: Summe der Einflussfaktoren

9 Bild 3.5 Function-Point-Verfahren, Ermittlung der MannMonate MM FP MM FP MM 50 2, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,7

10 Bild 4.1. Beispiel: Verbundentscheidungstabelle Auszug Pflichtenheft: Seminarorganisation : Wenn sich ein Kunde zu einem Seminar anmeldet, muss folgendes passieren: Prüfen - ob der Kunde bekannt ist - ob es dieses Seminar gibt - ob noch ein Seminarplatz frei ist - ob Zahlung vorliegt Folgende Aktionen (Funktionen) sind spezifiziert: A1: Anmeldedaten eintragen A2: Teilnehmerzahl erhöhen A3: Anmeldebestätigung versenden A4: Rechnung versenden A5: anlegen A6: Kunden neu eintragen A7: Seminar existiert nicht, Fehler melden A8: Seminar voll; Ausbuchung melden A9: an Zahlung erinnern A10: Zahlung prüfen A11: Buchung bestätigen Bedingungen: B1: Kunde bekannt B2: Seminar findet statt B3: bereits angemeldet? B4: Teilnehmer < max B5: Zahlung erfolgt Abhängigkeiten von Bedingungen prüfen: B3 kann nur geprüft werden, wenn B1 und B2 erfüllt sind B4 kann nur geprüft werden, wenn B2 erfüllt ist B5 kann nur geprüft werden, wenn B1 erfüllt ist d.h. nur B1 und B2 können unabhängig geprüft werden Gesucht ist die Entscheidungstabelle

11 Bild 4.2. SA Datenflusshierarchie A 0 C Kontextdiagramm A1 1 A3 2 A2 3 C DFD 0 Ai1 1.2 A2 A1 1.1 Ai2 1.3 A3 DFD 1 Mini Spezifikation 1.1. Minispezifikation im Pseudocode: z.b. if Kunde hat seine Rechnung bezahlt then löse Lieferung aus else sende Mahnung end if Rechnungsdaten eintragen in Speicher Rechnungen

12 Bild 4.3. Hierarchiekonzept in RT/SA A 0 C Kontextdiagramm und Zeitspezifikationstabelle pspec 1 FD 0 A1 0.2 A3 0.1 A2 0.3 C Cspec 0 pspec 3 Ai1 2.2 A2 FD 2 A1 2.1 Ai2 2.3 A3 Cspec 2 pspec 2.1. pspec 2.2. pspec 2.3 Requirements Dictionary: alle Daten- und Kontrollflüsse - Prozesse erhalten auf der letzten Verfeinerungsstufe eine psec - Diagramme können einen oder mehrere Balken enthalten, die durch eine Cspec repräsentiert werden - Prozessaktivierung wird nicht im FD dargestellt, sondern Prozessaktivierungstabelle und/oder Zustandsgraph

13 Bild 4.4.Klassenmodell Sitzungsorganisation Sitzung Sitzungsnummer: int termin: Datum einladen () Teil name: string format: string Teil_drucken () 2 * Anwesende Teilnehmer Name: string einladen () Gast zusage: boolean = false zusagen () 1 * bestätigt Sitzungsleiter honorar: int honorar_zahlen() anleiten () bestätigen() Sitzungsunterlagen Bestandteile: Teil[1 *] 1 * 1 Hilfskraft erstellen ( t:teil[1 *] ) leitet an 1 * <<structure>> datum Tag Monat Jahr

14 Bild 4.5. Beispiele von Use Case Modellen Anwendung als Kontextdiagramm: Kunde Bestellung Rechnung Ware Geld WWW- Shop Lieferant Bestellung Rechnung Ware Geld - dient der Abgrenzung von Systemen - zeigt Ein- und Ausgangsdatenfluss Use-Case-Beschreibung Kauf-Verkauf einer Ware Kunde <<include>> Ware bestellen EP:neuKunde <<include>> Kunde erfassen Lieferung einleiten Lieferant <<extend>> Kunde prüfen <<include>> Finanzen prüfen Neukunde

15 Bild 4.6. Beispiel eines Aktivitätsdiagramms Automatenverkauf Kunde Ware wählen Geld entnehmen Geld eingeben Ware Ware entnehmen Automat Fehler melden Geld ausgeben Geld [alle] Verfügbarkeit prüfen Ware ausgeben Geld zählen [nicht alle] Abbruch Wechselgeld berechnen [Geld< Preis] Geldvorrat alle Protokoll Exeption Handler

16 Bild 4.7. Beispiel eines Sequenzdiagramms Waschmaschine Bediener Ventil Wäsche trocknen Steuerung +öffnen() + schließen() Bediener <<extend>> Wäsche waschen +einschalten() Motor Pumpe +abpumpen() Use Case und Klassenmodell + waschen() + schleudern() Heizung +heizen() sd waschen :Bediener einschalten :Steuerung :Ventil : Motor : Pumpe öffnen : Heizung heizen(t=90 ) schließen waschen par schleudern abpumpen einschalten:fertig

17 Bild 4.8. Beispiel eines Zustandsdiagramms Kunde 1 0..* 1 1 Bankautomat Konto lesen Konto abheben Autentifizieren sm Authentifizieren wartend [Karte eingeführt] [Karte = keine Bankkarte]/ Karte auswerfen [PIN korrekt] Bankkarte_ok entry/karte prüfen PIN-Eingabe PIN eingegeben [PIN falsch]#++ [gültig=true] [#<3] [# 3]/Karte einziehen [gültig = false] /Karte [Abbruch]/Karte ausgeben

18 Bild 5.1. Konzepte zur Integration von Klassen Wurzelklasse - gibt an, dass eine Methode mit einer vorgegebenen Schnittstelle in den erbenden Klassen zu implementieren ist Spezialisierung Abstrakte Klasse Methode () Konkrete Klasse A - Knotenklasse implementiert die Methode für eine erbende Klassengruppe mit der vorgegebenen Schnittstelle Knotenklasse A Methode () Methode() Knotenklasse B Methode () Konkrete Klasse A1 Konkrete Klasse A2 Schnittstellen- Klasse Methode (Schnittstelle) - Schnittstellenklasse, verbindet Methodenimplementierer und Methodennutzer

19 Bild 7.1. Zur Berechnung von EM Effort Multiplier RCPX: Product Reliability and Complexity Effort Multiplier PDIF: Plattform Difficulty

20 Bild 7.2. Zur Berechnung von EM Effort Multiplier PERS: Personal Capability Effort Multiplier PREX: Personal Experience

21 Bild 7.3. Zur Berechnung von EM Effort Multiplier FCIL: Facilities Fax, etc. TOOL: 1 Editor, Compiler, Debugger 2 einfache CASE-Umgebung, schlechte Integration 3 moderat integriert 4 gute Case Umgebung, moderat integriert 5 gute Prozessintegration 6 aktive Case Umgebung Site: 1Telefon, Post 2 individuelles Telefon und Fax 3 , niedrige Bandbreite 4 mit großer Bandbreite 5 großer Bandbreite, auch Videokonferenzen 6 Interaktive Multimedia Effort Multiplier SCED: Schedule - es steht mehr bzw. weniger Zeit zur Verfügung