Folien zum Software Engineering Aus urheberrechtlichen Gründen (Verletzung von Rechten Dritter)...

Folien zum Software Engineering

Aus urheberrechtlichen Gründen (Verletzung von Rechten Dritter) dürfen Sie diese Foliensammlung nicht öffentlich zur Verfügung stellen (www oder ftp)!

Mein Dank gilt allen Studierenden, die insbesondere durch aufwendige grafische Darstellungen und Diagrammbeispiele zu dieser Foliensammlung beigetragen haben.

1

Hinweis zum Ausdrucken

Falls Sie diese Folien ausdrucken möchten, wird dringend empfohlen, Handzettel mit 9 Folien je Druckseite anstatt für jede Folie eine eigene DIN-A4-Seite auszudrucken. Dies erreichen Sie, indem Sie im Menü Datei/Drucken ... in das untere Listenfeld "Drucken:", wo steht "Folien" die Zeile "Handzettel (9 Folien je Seite)" auswählen.

2

Struktur der Vorlesung

Grundlagen Warum SE?, Grundprinzipien, Qualitätsmerkmale von

Software, Quantitative Trends

Methode (oder „Vorgehensmodell“, „Prozessmodell“) als allumfassender Ansatz zur Bewältigung großer Entwicklungsprojekte

Betrachtung einzelner Phasen sowie ausgewählter Ergebnisse und Techniken (Lastenheft, Funktionspunkte, UML)

3

Vorlesung und Übungen

Theorie Techniken CASE-Tool

Folienunter-stützteBehandlungdesLernstoffes

Übungen inderVerwendungeinzelnerModellierungs-techniken(z.B. ERD,DFD)

Durchlaufendes Kreislaufsvom ModellzumgeneriertenProgramm undzurück

4

Literatur zum Thema Software-Engineering (Kahlbrandt) B. Kahlbrandt: Software-Engineering:

Objektorientierte Software-Entwicklung mit der Unified Modeling

Language, Springer Verlag, 2. Aufl. 2001, ISBN: 3540416005 (Balzert1) H. Balzert: Lehrbuch der Softwaretechnik (Band 1):

Software-Entwicklung, Spektrum Akademischer Verlag, (2001) (Balzert2) H. Balzert: Lehrbuch der Softwaretechnik (Band 2):

Software-Management, Softwarequalitätssicherung, Unternehmensmodellierung, Spektrum Akademischer Verlag (1998), 769 Seiten

5

Literatur zum Thema Software-Engineering (im WWW) (Schürr1) http://www.es.tu-darmstadt.de/lehre/

ss08/se_i/download/skript/SE1.pdf (Schürr2) http://www2.informatik.unibw-

muenchen.de/Lectures/HT99/SEU/ (Gruhn) http://ls10-www.informatik.uni-

dortmund.de/LS10/Pages/Lehre-WS9899.shtml#SoftTech

(Prechelt) http://wwwipd.ira.uka.de/~prechelt/swt2/

(SE-VV) http://www.fh-deggendorf.de/doku/fh/meile/bachelor/lehre/st/index.html

6

Inhalt (1)

Einführung Motivation Grundprinzipien des SE Qualitätsmerkmale von Software Quantitative Trends

Was bietet die Informatik? Vorgehensmodelle Übergang zum Projektmanagement Werkzeuge: CASE Beschreibung und Schätzung der Projektaufgaben

Das Lastenheft Aufwandsschätzung mit dem Funktionspunkteverfahren

Modellierungstechniken „Klassische“ Techniken

Entity Relationship Diagramm Datenflussdiagramm

7

Inhalt (2)

– UML (objektorientiert)• Grundlagen der Objektorientierung• Use-Case-Diagramm• Aktivitätsdiagramm• Klassendiagramm• Sequenzdiagramm• Kommunikations-/Kollaborationsdiagramm• Zustandsdiagramm

– Systembeschreibende Diagramme:• Paketdiagramm• Komponentendiagramm• Verteilungsdiagramm

• Übergang zur Programmierung / Codegenerierung• Möglichkeiten der Codegenerierung aus Diagrammen

8

Inhalt (3)

• Testen– Überblick– Fehler– Statische Verfahren– Dynamische Verfahren

• Qualitätssicherung– ISO 9000– TQM– CMM

• Weitere Vorgehensmodelle– XP (Extreme Programming)

9

Motivation

Gründe für SE (Auswahl) Umfang der Entwicklungsprojekte Arbeitsteilung in der Softwareentwicklung Komplexität der Anwendung Hohe Anforderungen an Qualität

Zuverlässigkeit Sicherheit (z. B. Wehrtechnik, Luft- und Raumfahrt) eingebettete Software

10

Motivation

Zahlreich sind die Berichte über erhebliche Kosten- und Terminüberschreitungen Softwareprojekte, die nach Jahren der

Anstrengung und erheblichem Aufwand erfolglos aufgegeben wurden

„winzige Versäumnisse“ im Entwicklungsprozess mit zum Teil katastrophalen Folgen

Auslieferung unreifer, fehlerhafter Software

11

Wegen Punkt statt Komma abgestürzt: Das Mariner-Unglück Mariner 1 (Venus Sonde) mußte 4 Min. nach dem

Start wegen unberechenbarem Flugverhalten zerstört werden. Gerüchten zufolge war aber ein Software-Fehler schuld: während des Starts sollte eine bestimmte Anweisung 3 x ausgeführt werden

DO 3 i= 1, 3 Tippfehler DO 3 i= 1. 3 ... (Aktion) ... 3 CONTINUE Dazu muß man über FORTRAN wissen:

Spaces spielen keine Rolle; dadurch wird der Ausdruck DO3i= 1.3 zu einer Wertzuweisung

Variablen brauchen nicht deklariert zu werden12

Was ist SE

Ingenieurmäßiges Vorgehen Der Begriff Software Engineering wurde im

Jahre 1968 auf einer Konferenz der NATO in Garmisch/Partenkirchen geprägt.

Zur Zeit der damals aufkommenden und noch immer nicht bewältigten „Softwarekrise“

13

Exkurs: SE und Wissenschaft (Prechelt 1999) „Die Softwaretechnik als praktische technische Disziplin hat heute

wenig wissenschaftlichen Charakter. Das vorhandene Wissen stammt überwiegend aus einer Mischung von Intuition und Empirizismus und ist nur in wenigen Fällen wissenschaftlich abgesichert, denn die meisten Beiträge sind Entwürfe (von Modellen, Methoden oder Werkzeugen) und stellen insofern nur Hypothesen dar -- und selbst diese werden meist nicht klar ausgesprochen. Geprüft werden diese Hypothesen bislang nur selten; nicht zuletzt deshalb, weil eine solche Prüfung in der Softwaretechnik meist enorm aufwendig ist.

So wissen wir beispielsweise herzlich wenig darüber, welche Eigenschaften von z.B. Entwurfsmethoden, Programmiersprachen oder Entwicklungswerkzeugen welche Qualitätsattribute der Produkte in welcher Weise beeinflussen, obwohl diese Fragen den Kern unseres Faches betreffen. Wir wissen auch fast nichts darüber, welche Fehler in welchen Situationen gemacht werden und welche Maßnahmen das verhindern könnten, oder wie man die Fehler zumindest schnell wieder findet und behebt.

14

Exkurs: SE und Wissenschaft (Prechelt 1999) Als Folge dieses Zustands arbeiten vermutlich die allermeisten

softwareerzeugenden Organisationen weit unterhalb ihrer Möglichkeiten, was ihre Produktivität und die Qualität ihrer Produkte angeht.

Eine entscheidende Beobachtung in diesem Zusammenhang lautet, dass die grundsätzliche Arbeitsweise der wissenschaftlichen Methode in abgeschwächter Form auch für sehr praktische Problemstellungen in der Anwendung der Softwaretechnik verwendet werden könnte und sollte. Zum Beispiel kann die Auswahl des besseren von zwei Werkzeugen in der Regel durch ein entsprechend gestaltetes Experiment erledigt werden, wenn zuvor eine klare Fragestellung vorliegt (Was heißt ,,besser``? In welchem Zusammenhang?) und etwas Aufwand investiert wird. Dieser Aufwand könnte sich in vielen Fällen leicht amortisieren, und dennoch werden solche Untersuchungen bisher selten gemacht.“

15

Prinzipien des SE

Abstraktion / Modellierung Schrittweise Verfeinerung / Hierarchisierung Modularisierung Vgl. Gruhn , F. 46 ff.

16

Qualitätsmerkmale von Software

korrekt robust zuverlässig effizient es gibt noch viele offene Wünsche:

wartbar, wiederverwendbar, portierbar, kompatibel, benutzerfreundlich, interoperabel

17

Quantitative Trends

Steigender Anteil von Software am Bruttosozialprodukt

Mehr als die Hälfte der Wertschöpfung von Siemens (von Pierer nach Balzert 1989)

Steigender Softwareanteil an technischen Produkten (z. B. bei Anlagen der digitalen Vermittlungstechnik bis zu 80%: Quelle BMFT 1995, S. 3 )

Für 50 % der Ausfälle im industriellen Sektor sind Software-Fehler verantwortlich. (Balzert 1998)

18

SoftwarekriseKosten

Zeit1940 1968 1990

Hardwarekosten

Softwarekosten

Quelle: Herde vhb19

Aus: Schürr121

Abbruchrate

Aus: Gruhn, F. 16

22

Kostenstruktur eines Software-Projekts (in der Software-Branche anerkannte Daumenwerte aus Pieper): Entwicklungskosten 33%

Analyse und Entwurf 40% Codierung 20% Test 40%

Wartungskosten 66% Fehlerkorrektur 20% Verbesserungen 55% Portierung 25%

Oft wird auch ein 80:20 Verhältnis zwischen Wartungs- und Entwicklungs-kosten genannt

23

Kostenfaktoren (aus Pieper)

Änderungen in den Benutzeranforderungen Änderungen in Datenformaten Notfallrettungsaktionen Routinefehlerbehebung Hardware-Änderungen Dokumentation Verbesserungen Sonstiges

24

Wie groß sind bekannte Programme? SAP R/3 (1994):

7.000.000 Zeilen Sourcecode 100.000 Funktionsaufrufe 20.000 Funktionen 17.000 Menüleisten 21.000 Reports

· Space Shuttle 48.000.000 Instruktionen

· EWSD (elektronisches Wählsystem ISDN) ? Instruktionen

25

Was weiß der Softwareingenieur? Dass er zuerst ein Modell erstellen muss

(Grundprinzip) Wie er ein Projekt mit mehreren Personen

plant und organisiert (Vorgehensmodell) Wie er das zu erstellende Programm formal

beschreiben kann (Modellierungstechniken) Wie er Werkzeuge zur Unterstützung der

Softwareentwicklung benutzen kann (z.B. CASE)

26

Was bietet die Informatik?

Prinzipien des SE Prozessmodelle / Vorgehensmodelle Modellierungstechniken Werkzeuge (Programme zur Unterstützung

der Softwareentwicklung)

27

Was beinhalten Prozessmodelle? Vorgehensmodell Ergebnisse Techniken Tool Rollen

• Wann

• Was

• Wie

• Womit

• Wer

28

Verbindung zwischen den Begriffen Ein Prozessmodell ist eine Vorschrift, wann

welche Ergebnisse mit Hilfe welcher Techniken zu erstellen sind.

Zusätzlich kann festgelegt sein, von wem (Rolle) und womit (CASE-Tool) die Ergebnisse zu erstellen sind.

Beispiel: In der Phase „Analyse“ ist mit der Technik "Entity-Relationship-Diagramme" das Ergebnis "Datenmodell" zu erstellen.

Ergebnisse können Diagramme, Listen, unstrukturierte Texte, Quellcode etc. sein

29

Typisches Vorgehensmodell

Vorstudie / Planung Analyse Design Konstruktion Test Einführung

30

Vorgehensmodellvarianten

Wasserfallmodell jede Phase wird einmal durchlaufen Problem nachträglicher Änderungen

Iteratives Modell / Spiralmodell die mittleren Phasen werden wiederholt

durchlaufen bis Zufriedenheit mit dem erreichten Ergebnis besteht

31

Vorgehensmodelle: Empirie

„Derzeit folgt ungefähr die Hälfte aller [deutschen] Unternehmen einem definierten Vorgehensmodell ...

Überwiegend handelt es sich dabei um unternehmenseigene Vorgehensmodelle“

(Quelle:http://www.dlr.de/IT/IV/Studien/evasoft_abschlussbericht.pdf)

32


„Es ist ein deutlicher Trend hin zu iterativen Vorgehensmodellen zu erkennen. Dies reflektiert die Erkenntnis, dass Kosten- und Liefertreue nur durch inkrementelle (sequentielle oder parallele) Entwicklung der Software garantiert werden kann.“


33


„Allerdings ist zu beobachten, dass die Einhaltung von Vorgehensmodellen überwiegend in das Ermessen einzelner Entwicklungsabteilungen gestellt wird; es gibt hier noch wenig Verbindlichkeit.“


34


„Es muss hier noch darauf hingewiesen werden, dass bei fast allen befragten Unternehmen keine Unterscheidung zwischen Vorgehensmodellen zur Projektdurchführung (mit Definitionen von Projektmeilensteinen) und Prozessmodellen (mit Definitionen zur Durchführung technischer Entwicklungsschritte wie Entwerfen) gemacht wurde. Letztere existieren i.A. überhaupt nicht. [Also das, was wir hier in den Übungen durchexerzieren!!] Die technische Softwareentwicklung wird der Kreativität der Entwickler überlassen. Dies deutet daraufhin, dass bei einigen Unternehmen Kosten- und Zeittreue Vorrang haben vor Qualitätstreue. Dies stellt einen gewissen Widerspruch zu den von den meisten Unternehmen als wichtig erkannten Qualitätseigenschaften dar.“


35

Weitere Trends

Zunehmende Bereitschaft, frühzeitig Reviews durchzuführen

Gezielte Risikominimierung durch inkrementelle Prozesse bzw. „kleine Schritte“

Nutzung der Komponententechnologie

(Quelle:http://www.dlr.de/IT/IV/Studien/evasoft_abschlussbericht.pdf, p. 10)

36

SE-Management in Organisationen

In einem Unternehmen gibt es Leute, die die Software möchten und dafür zahlen.

Sie möchten aber vorher wissen, wie lange es dauern wird und was es kosten wird.

Ein Projekt muss geplant und gemanagt werden! Es muss klar sein, wer wofür, wann gebraucht

wird und wer - auch nach Einführung der Software - für was verantwortlich ist!

37

Projekte

Ergebnis / Projektziel einmalig und in überschaubarem Zeitraum

erreichbar temporäre, arbeitsteilige Organisation

neben der bestehenden Aufbauorganisation / Projektgruppe

Betrachtung aus wirtschaftlicher Sicht / Projektcontrolling

38

Projektmanagement / Planung

Aktivitäten Ressourcen (Kapazitäten und Mitarbeiter) Termine Kosten

39

Projektmanagement / Steuerung

Kontrolle von Leistungen, Kosten und Terminen

Koordination Information der Projektmitglieder und

Berichterstattung an den Lenkungsausschuss

41

Projektmanagement / Kontrolle

Einhaltung des Projektplans Abweichungsanalyse Projektreviews (eventuell durch externe,

unabhängige Spezialistenteams)

42

Der Projektmanager

Gutes Projektklima sichern Kontakt zu sonstigen vom Projekt berührten

Stellen pflegen Ressourcen beschaffen Vertretung von Teammitgliedern

43

Das Projektteam

IT-Spezialisten Vertreter aus dem Anwendungsbereich mit

genügend Zeit und Lernbereitschaft Kommunikative Fähigkeiten sind gefragt 5-7 Personen

44

Die Projektphasen

Ziele, Aktivitäten und Ergebnisse pro Phase Entscheidungszeitpunkte (Phasenenden)

Projektleiter berichtet an Kontrollgremium („Steuerungsausschuss“)

Planung und Einteilung der Phasen gemäß innerbetrieblicher Vorgaben (selbstgestrickte oder eingekaufte Methoden / Vorgehensmodelle)

45

Entscheidung nach Phasenende

The result of the Lifecycle Milestone Review Meeting can be one of the following:

Phase Accepted: The customer representative agrees that the project has met expectations for the phase, and can proceed to the next phase.

Conditional Acceptance: The customer representative agrees that the project may proceed to the next phase, subject to the completion of specified corrective actions.

Phase Not Accepted: The project has failed to achieve the expectations for the phase: either a further iteration is scheduled, or the various stakeholders have recourse to the contract, to re-scope or terminate the project.

46

Phasen von Rational Unified Process

47

Rollenverteilung

Tester

Qualitäts-Manager

Projektleiter

Designer

Marketier

Vors. GF

Kunde

Programmierer

Budget-Controller

FordertNachbesserung

VersendetWerbematerial

Vertriebler

KündigtProdukt an

ÜberprüftKostenberichte

Berichtet an

Berichtet an

Macht Vorgaben

Liefert Spez.

LiefertProgramm

Überprüft ArbeitsergebnisseÜberprüft ArbeitsergebnisseA

B

C

A steht zu B in der Beziehung C

Gruhn, F.26

48

CASE

CASE Einführung Rational Rose Andere Tools

49

CASE

Computer Aided Software Engineering Editoren zur Erstellung von Diagrammen Gemeinsames Repository / Enzyklopädie Automatische Generierung von

Programmcode und Datenbankspezifikation

50

Die wichtigsten Vorteile von CASE Integration bzw. Konsistenzerhaltung

zwischen den Phasenergebnissen (vertikal) Daten und Funktionen (horizontal)

Automatische Dokumentation Spätere Änderungen leichter bei

Vorhandensein eines Modells (Wartungsproblem)

51

CASE-Tool: Beispiele

52

CASE-Tool: Beispiele

53

Funktionsstruktur

54

Datenstruktur

58

Relationenmodell

61

CASE-Tool Links

http://osiris.sunderland.ac.uk/sst/case2/tools.html

http://www.inf.tu-dresden.de/~rm1/bookmark.html

http://www.qucis.queensu.ca/Software-Engineering/

http://argouml.tigris.org/ (freies UML-Tool Argo)

http://www.gentleware.com (freies UML-Tool Poseidon)

http://www.rational.com

62







http://argouml.tigris.org/

http://www.gentleware.com/

http://www.rational.com/

Struktur eines Lastenhefts

1. Zielbestimmung Die Kinoangestellte soll in der Lage sein, Eintrittskarten für

einen bestimmten Film (in einem bestimmten Kinosaal) und einen bestimmten Platz zu verkaufen.

2. Produkteinsatz: Das Produkt dient zur Platzverwaltung bei Filmvorstellungen

in Kinos. Zielgruppe ist der/die Verkäufer(in) der Eintrittskarten.

3. Produktfunktionen: /LF10/ Erfassung, Änderung und Löschen von Filmdaten /LF20/ Erfassung, Änderung und Löschen von

Platzreservierungen

63

Struktur eines Lastenhefts (2)

4. Produktdaten /LD10/ Filmdaten /LD20/ Kundendaten

5. Produktleistungen /LL10/ Eine Platzreservierung ist bei Nichtabholung der Karte 30

Minuten vor Beginn der Vorstellung automatisch zu löschen

Gewünschte Qualität Funktionalität: gut Zuverlässigkeit: sehr gut Benutzbarkeit: einfach Effizienz: normal Änderbarkeit: gut Portierbarkeit: irrelevant

64

Beispiel (2)

Lastenheft „Bestellsystem für Pizzaservice“

Version 1.0 Datum: 13.12.01

1. Zielbestimmung Der Pizzaservice „Rapido“ soll in die Lage

versetzt werden, Kundendaten und telefonische Bestellungen mit einem EDV System zu verarbeiten.

65

Beispiel (3)

2. Produkteinsatz Das Produkt dient zur Verwaltung von

Kunden und Bestellungen. Zielgruppe sind die Mitarbeiter des Pizzaservice.

66

Beispiel (4)

3. Produktfunktionen (LF = Lastenheftfunktionen) /LF10/ Erfassung, Änderung und Löschen von Kundendaten /LF20/ Erfassung, Änderung und Löschen von Produktdaten /LF30/ Abfrage der relevanten

Kundendaten /LF40/ Erfassung eines Bestellvorgangs /LF50/ Ausgabe von Backauftrag,

Lieferauftrag und Rechnung67

Beispiel (5)

4. Produktdaten (LD = Lastenheftdaten) /LD10/ Relevante Kundendaten sind

zu speichern /LD20/ Relevante Produktdaten sind

zu speichern /LD30/ Relevante Bestelldaten sind

zu speichern

68

Beispiel (6)

5. Produktleistungen (LL = Lastenheftleistungen)

/LL10/ Die Funktionen /LF30/ und /LF50/ sollen jeweils maximal 5

Sekunden in Anspruch nehmen.

/LL20/ Es sollen maximal 1000 Kunden und 200 Produkte verwaltet werden.

69

Beispiel (7)

6. Gewünschte Qualität Funktionalität: gut Zuverlässigkeit: sehr gut Benutzbarkeit: gut Effizienz: normal Änderbarkeit: normal Portierbarkeit: irrelevant

70

Aufwandsschätzung

Das wichtigste Verfahren ist das Function-Point-Verfahren

in der Industrie weit verbreitet dadurch sehr gut fundierte Vergleichsbasis ein empirischer Vergleich mehrerer

Methoden ergab Genauigkeit der Schätzung im Bereich von +- 11% (Balzert 1996; 77)

71

Vorteile der Function-Points (nach: Jenny) frühzeitig anwendbar (Basis ist die

Anforderungsanalyse, das Lastenheft) genauer später iterativ anwendbar Ergebnis ist erklärbar und nachvollziehbar für die Bewertung wird die Gesamtheit der

Anforderungen herangezogen, eine Gliederung ist nicht erforderlich

72

Function-Points: Vorgehen

1. Quantifizierung des Projektumfangs nach Komponenten/Functions

2. Bewertung des Schwierigkeitsgrades je Function durch Points

3. Analyse der 7 Einflußfaktoren 4. Berechnung der bewerteten Function

Points 5. Ermittlung des Aufwands mittels

historischer Daten73

Function-Points

Bewertung des Schwierigkeitsgrades Einteilung jeder Komponente in die

Komplexitätsstufen einfach, mittel oder komplex

Zuordnung von Funktionspunkten zwischen 3 und 15 je nach Komponente und Komplexitätsstufe

verschiedene Bewertungsvarianten in der Literatur

74

Function-Points: Komponenten

Eingabedaten zählen (mit unterschiedl. Format oder Verarbeitungslogik), z. B.: Bildschirmeingaben, Eingaben über Diskette, Interfacedaten anderer Anwendungen,...

Ausgabedaten, z. B.: Bildschirmausgaben, Listen, Formulare, Interfacedaten für andere Anwendungen

75

Function-Points : Komponenten

Abfragen gezählt wird jeweils eine Einheit von

unterschiedlich formatierten Online-Eingaben zur Suche von Information

Anwenderdateien gezählt wird jede logische Datei , die im Rahmen

des Anwendungssystems gepflegt wird

Referenzdateien alle Dateien und Tabellen, die von der Anwendung

nur gelesen werden76

Funktion Points

Eingabedaten Abfragen AusgabedatenDatenbestände Referenzdaten

Produktanforderungen

einfachmittel

komplex

Einflussfaktoren 0 - 60

Eingabedaten 3 mittel x 4 12Abfragen 1 einfach x 3Ausgabedaten 2 .... ...DatenbeständeReferenzdaten

1

2 2 2 2 2

3

4

5

290

Anzahl Gewichtung

vgl. H. Balzert: Lehrbuch der Software-Technik, 2000290 x 0,95577

Eingabedaten

78

Ausgabedaten

79

Alternative Bewertung für die Komponente Ausgabedaten:

80

Datenbestände

81

Abfragen

82

Referenzdaten

83

Festlegen der Einflussfaktoren der gesamten Anwendung

Bewertung der Faktoren mit 0 bis 5 Punkten (je Faktor)

(0 .. kein Einfluss, 5 .. starker Einfluss) Einflussfaktoren:

EF1: Verflechtung mit anderen Systemen EF2: Dezentrale Verarbeitung und Datenhaltung EF3: Transaktionsrate und Antwortzeitverhalten

84


EF4: Verarbeitungskomplexität; Bewertungsspanne hier 0-30 ergibt sich aus der Summe der Einzelbewertungen (angepasst durch IBM-Deutschland, 1985) für:

+ Schwierigkeit und Komplexität der Rechenoperationen (0-10)+ Umfang der Kontrollverfahren für die

Datensicherstellung (0-5)+ Anzahl der Ausnahmeregelungen (0-10)+ Schwierigkeit und Komplexität der Logik (0-5)

85


EF5: Wiederverwendbarkeit in anderen Anwendungen:z.B.: prozentualer Anteil der Wiederverwendung: bis 10% .. 0 FP, über 50% .. 5 FP

EF6: Datenbestand-Konvertierungen EF7: Benutzer- und Änderungsfreundlichkeit Addition der Einflussfaktor-

Bewertungspunkte: =EF max(EF) = 60

86

Berechnung der bewerteten “Total Function Points” TFP TFP = FP * (0,7 + (0,01 * EF)) Wertebereich der Modifikation der

Function Points durch die Einflussfaktoren: 0,7 - 1,3,

d.h. der Einfluss der Faktoren kann (bei Kommerz. Anwendungen) maximal ±30% des errechneten Wertes betragen;

87

Ableitung nach Erfahrungstabelle bzw. -kurve

88

FP-MM "IBM-Wertepaare"

0

500

1000

1500

2000

2500

3000

3500

0 100 200 300 400

Mitarbeitermonate

Bew

erte

te F

un

ctio

n P

oin

ts

Aufwand

5

Aktualisierung

6

7

Funktion Points

vgl. H. Balzert: Lehrbuch der Software-Technik, 2000

290 x 0,955 = 276,95

89

LOC pro Point

C 128 C++ 51 HTML 3.0 15 Java 29 Pascal 91 SQL 13 Visual Basic 5 29

90

Vorschlag Balzert, 2001, S88f.

Einflussfaktoren (jeweils 0-6 Punkte) Produktleistungen Qualitätsanforderungen GUI-Anforderungen Nichtfunktionale Anforderungen Anzahl und Komplexität der Schnittstellen Algorithmische Komplexität Architektur Werkzeugeinsatz (umgekehrt proportional) Erfahrung der Mitarbeiter (umgekehrt proportional) Reife des Entwicklungsprozesses (umgekehrt

proportional)

91

2.2 Anwendung im Detail und am Beispiel Das Beispiel:

Ein Pizzaservice möchte seine Bestellungen mit einem EDV-System verarbeiten.

Es liegt ein Lastenheft vor. (siehe oben) Entwicklungsaufwand des geforderten

Software-Systems soll vorab geschätzt werden.

92

Anwenden der Function Point Methode (1)

1. Schritt Einordnung der Produktanforderungen

in Kategorien

93

Anwenden der Function Point Methode (2) Einordnung der Produktanforderungen

am Beispiel Datenbestände:

vom System verwaltet im System verwendet hier:

/LD10/: Kundendaten /LD20/: Produktdaten /LD30/: Bestelldaten

94

Anwenden der Function Point Methode (3) Referenzdaten:

in externem System vorgehalten von externem System verwaltet im System verwendet hier: nicht vorhanden Beispiel: Bestellung beim

Zulieferer Zugriff auf Bestände

und Preise des Lieferanten

95

Anwenden der Function Point Methode (4) Eingabedaten:

elementarer Prozess Daten oder Kontrolldaten Pflege der Datenbestände hier:

/LF10/: Pflege der Kundendaten /LF20/: Pflege der Produktdaten /LF40/: Eingabe der Bestelldaten

96


Abfragen: einfacher, elementarer Prozess einfache Ausgabe von Daten keine weitere Verarbeitung hier:

/LF30/: Anzeige der Kundendaten

97

Anwenden der Function Point Methode (6) Ausgabedaten:

elementarer Prozess Ausgabe von Daten durch mathematische Funktion errechnet durch Prozesslogik abgeleitet hier:

/LF50/: Ausgabe von Backauftrag, Lieferauftrag und Rechnung

98


2. Schritt: Klassifizierung der Funktionen und

Daten Eingabedaten:

99


Ausgabedaten und Abfragen

100


Datenbestände und Referenzdaten

101

Anwenden der Function Point Methode (10) Klassifizierung im Beispiel:

Zusatzannahmen notwendig z.B. Rücksprache mit Auftraggeber

Eingabedaten: /LF10/: Kundendaten

ein Datentyp sechs Datenfelder einfach

102


/LF20/: Produktdaten

ein Datentyp vier Datenfelder einfach

/LF40/: Bestelldaten

drei Datentypen zehn Datenfelder komplex

103


Abfragen:

/LF30/: Abfrage der Kundendaten

ein Datentyp sechs Datenfelder einfach

104


Ausgabedaten:

/LF50/: Ausgabe von Backauftrag, Lieferauftrag und Rechnung

drei Datentypen 20 Datenfelder komplex

105


Datenbestände:

/LD10/, /LD20/, /LD30/

jeweils ein Datentyp weniger als je 20

Datenfelder alle einfach

106


3. Schritt Berechnung der unbewerteten Function

Points

107


4. Schritt:

Bestimmung von Einflussfaktoren Auf- oder Abwertung der unbewerteten Function Points um 30 Prozent

108

Anwenden der Function Point Methode (16) Einflussfaktoren im einzelnen:

Verflechtung mit anderen Anwendungssystemen

dezentrale Daten, dezentrale Verarbeitung Transaktionsrate Verarbeitungslogik Wiederverwendbarkeit Datenbestandskonvertierungen Anpassbarkeit

109

Anwenden der Function Point Methode (17) Die Einflussfaktoren im Beispiel:

Verflechtung mit anderen Anwendungssystemen (0-5)

hier nicht gegeben: 0

dezentrale Daten, dezentrale Verarbeitung (0-5) hier nicht gegeben: 0

110


Transaktionsrate (0-5)

Zusatzannahme: Einzelplatzsystem häufige Bestellannahme hier mittlere Transaktionsrate: 3

111

Anwenden der Function Point Methode (19) Verarbeitungslogik (0-30)

Aufteilung in vier Bereiche

A) Rechenoperationen - wenige, einfache Rechenop.:

1 B) Kontrollverfahren - hier keine: 0 - denkbar:

Warenbestandsprüfung112

Anwenden der Function Point Methode (20) C) Ausnahmeregelungen - hier keine: 0 - denkbar: unzuverlässige Kunden D) Logik - nur sehr einfache

Datenzusammenstellung - daher hier: 0 - denkbar: Routenplanung

113

Anwenden der Function Point Methode (20) Wiederverwendbarkeit (0-5) - nicht gefordert / keine Angaben:

0 Datenbestandskonvertierungen (0-5) - nicht erforderlich - Neuentwicklung - zuvor keine Daten erhoben - Bewertung: 0 Anpassbarkeit (0-5) - Lastenheft: Qualität normal: 2

114

Anwenden der Function Point Methode (20) C) Ausnahmeregelungen - hier keine: 0 - denkbar: unzuverlässige Kunden D) Logik - nur sehr einfache

Datenzusammenstellung - daher hier: 0 - denkbar: Routenplanung

115

Anwenden der Function Point Methode (20) Wiederverwendbarkeit (0-5) - nicht gefordert / keine Angaben:

0 Datenbestandskonvertierungen (0-5) - nicht erforderlich - Neuentwicklung - zuvor keine Daten erhoben - Bewertung: 0 Anpassbarkeit (0-5) - Lastenheft: Qualität normal: 2

116

Anwenden der Function Point Methode (21) Die bewerteten Funktion Points

siehe Blatt

Einflussbewertung E3 ermitteln Berechnung der bewerteten Function Points

117


6. Schritt Umrechnung in Mitarbeitermonate (MM)

firmenspezifische Tabelle oder Graph Function Points vs. MM empirische Daten notwendig ggf. Tabelle / Graph aus ähnlichem Umfeld

118

IBM - Tabelle

119


7. Schritt Aktualisierung der Tabelle „FP vs. MM“

nach Abschluss des Projektes tatsächlich benötigter Aufwand vs. berechnete,

bewertete Function Points Hinzufügen des Wertepaares Verbreiterung der Datenbasis ggf. gleichzeitiges Löschen des ältesten

Wertepaares

120

Modellierungstechniken

„Klassische“ Techniken ER-Diagramme Strukturierte Analyse (SA)/

Datenflußdiagramme (DFD) Nassi Shneidermann Struktogramme Pseudocode /Aktionsdiagramme

Objektorientierte Techniken UML (Beispiele)

121

Einordnung diverser Techniken

122

Entity-Relationship-Diagramme

Entität und Entitätstyp (auch Objekt und Objekttyp)

Attribut / Attributwerte Beziehung (Relationship) Kardinalität einer Beziehung weitere Informationen und Beispiele in der

Präsentation „ER-Datenmodell und Abfragen in SQL.ppt“ im Ordner „Datenbanken“

123

Kardinalität der Beziehungen

1:1 1:N M:N

124

Krähenfußnotation

1 ist senkrechter Strich N ist „Krähenfuß“

125

Auflösung einer M:N-Beziehung in zwei 1:N-Beziehungen Eine M:N-Beziehung kann in einer

relationalen Datenbank nicht direkt realisiert werden.

Durch die Zwischenschaltung einer zusätzlichen Tabelle wird sie aufgelöst in zwei 1:N-Beziehungen.

(Tabelle) Studentin besucht (Tabelle) Vorlesung wird ergänzt durch (Tabelle) Vorlesungsbesuch

126

Beziehungen

Optional oder obligatorisch Parallele Beziehungen (z. B. Person –

Versicherungspolice) Reflexive Beziehungen (z. B. zur

Darstellung der Mitarbeiterhierarchie)

127

Optionale Beziehungen

Kunde Bestellung

Kunden ohne Bestellung sind möglich. Beziehung ist optional. Beziehungen ohne „Null“ gelten dann als obligatorisch!

128

Obligatorische Beziehungen

Rechnung Rechnungsposition

Eine Rechnung ohne Rechnungsposition soll nicht vorkommen dürfen.

129

Reflexive Beziehungen

Mitarbeiter

Ist verheiratet mit

Ist Vorgesetzter von

130

Parallele Beziehungen

Person VersicherungspoliceIst Versicherungsnehmer

Ist Versicherte Person

131

Strukturierte Analyse

Meistbenutzte Technik in der Praxis Einfach zu erlernen

132

Strukturierte Analyse : Komponenten Hierachie von Datenflussdiagrammen Oberste Ebene heißt „Kontextdiagramm“ Beschreibung der Prozesse durch Mini-

Spezifikationen (z. B. Pseudocode) Beschreibung der Struktur der Daten im

Datenverzeichnis (Data Dictionary)

133

Elemente eines Datenflußdiagramms Prozesse Datenspeicher Datenflüsse Endknoten (Terminatoren)

134

Prozesse

Prozesse verarbeiten Daten

Buch vormerken

1.2

135

Datenspeicher

Vormerkungen

136

Endknoten (Terminatoren)

Endknoten sind Akteure oder Datenspeicher außerhalb des betrachteten Systems, die Daten senden oder empfangen.

Kunde

137

Datenflüsse

Datenflüsse transportieren Daten Sie können beschriftet werden

Vormerkungen

Buch vormerken

1.2 Akzeptierte Vormerkung

138

Datenspeicher

Direkte Verbindungen zwischen Datenspeichern sind verboten

Vormerkungen

Ausleihen139

Hierarchiekonzeptder „Strukturierten Analyse“

0.

3.

Kontext-Diagramm Ebene 0: Datenfluß-Diagramm

2.1.

Prozeßspezifikation

____________________________________________

140

Struktogramm (Auswahl)

Ausdruck

wahr falsch

Ja-Anweisung Nein-Anweisung (bei einseitiger Auswahl leer)

Anweisung(en)

Quelle: Herde vhb141

Pseudocodewhilewhile (Ausdruck)

{

Wiederholungsanweisung(en);

} Anweisung(en);

dodo{

Wiederholungsanweisung(en); }

whilewhile (Ausdruck);Anweisung(en); Quelle: Herde vhb142

Objektorientierung

Klassen und Instanzen (Instanz = Objekt) Attribute und Methoden Requests / Messages Vererbung und Klassenhierarchien Vorherrschendes Prinzip moderner

Programmiersprachen (Java, .Net) In der Datenbankpraxis jedoch bisher

unbedeutend

143

Diagramme der UML

Strukturdiagramme

Klassen-diagramm

Komponenten-diagramm

Kompositions-Strukturd.

Objekt-diagramm

Verteilungs-diagramm

Paket-Diagramm

Verhaltensdiagramme

Use-Casediagramm

Zustands-diagramm

Aktivitätsdiagramm

Interaktionsdiagramme

Sequenz-diagramm

Kommunikations-diagramm

Interaktions-übersichtsd.

Timing-diagramm 144

Quelle: Casetool MID Innovator

145

Use-Case Diagramm

146

Sequenzdiagramm

147

Klassendiagramm

148

Zustandübergangsdiagramm

150

Stereotypen von Klassen (Rose-Tutorial)

151

Zustandübergangsdiagramm

© H. Balzert 2001

152

UML-Klassendiagramm• In einer Schule soll der Lehrbetrieb folgendermaßen rechnergestützt

verwaltet werden:

• Jeder Lehrer kann bis zu vier Fächer unterrichten.

• Eine Klasse wird von verschiedenen Lehrern in unterschiedlichen Fächern unterrichtet.

• Jeder Klasse ist ein bestimmter Lehrer als Klassenlehrer zugeordnet.

• Der Klassenlehrer soll die Schüler seiner Klasse bei Problemen unterstützen. Deshalb darf jeder Lehrer nur für eine Klasse Klassenlehrer sein.

• Jede Unterrichtsstunde findet in einem bestimmten Raum zu einer bestimmten Zeit statt und wird von einem Lehrer in einem bestimmten Fach vor einer Klasse abgehalten.

• Jede Klasse hat zwischen 30 und 35 Unterrichtsstunden.

153

Eigenschaften von Aktivitätsdiagrammen

• Aktivitätsdiagramme = Kontrollflussdiagramme + Zustandsdiagramme

• Kontrollflussdiagramm:

• Zustandsdiagramm:

• Aktivitätsdiagramm

154

Eigenschaften von Aktivitätsdiagrammen

• Aktivitätsdiagramme = Kontrollflussdiagramme + Datenflussdiagramme

• Beschreibung von Datenfluss durch Parameter (wie bei Kontrollfluss, x = Objekt):

• Beschreibung von Datenfluss durch Objektangabe (wie bei Datenfluss):

155

Eigenschaften von Aktivitätsdiagrammen• Stärken

– Darstellung von nebenläufigen Prozessen• Technisch: Threads• Analytisch: Geschäftsprozesse

• Schwächen– Beziehung der Aktivitäten zu Objekten schlecht

sichtbar(Ausweg: Swimlanes oder Objektnamen in Aktivitäten aufnehmen)

156

Elemente

• Es gibt drei Kategorien von Nodes:– Action Node:

– Object Node:

– Control Nodes:

Ablaufendknoten Endknoten Splitting/Synchronisation Startknoten bedingte Verzweigung oder

Zusammenführung von

Aktionssträngen

157

Elemente - Fallunterscheidungen

• Eine Verzweigung ist ein Schritt im Ablauf, an dem aufgrund von Kriterien entschieden wird, mit welcher von mehreren Aktivitätskanten der Kontrollfluss fortgesetzt werden soll.

• Eine Zusammenführung ist ein Schritt im Ablauf, an dem jede von mehreren eingehenden Aktivitätskanten sofort zu einer gemeinsamen ausgehenden Aktivitätskante führt.

158

Elemente

• Fallunterscheidungen:Es darf keine Schnittmengen

zwischen den Bedingungen

geben (eine muss erfüllt sein):

159

Elemente – Parallele Abläufe

• Eine Synchronisation (AND-Verknüpfung) ist ein Schritt im Ablauf, an dem auf alle eingehenden Aktivitätskanten gewartet wird, bevor der Kontrollfluss fortgesetzt wird.

• Eine Teilung (Splitting) ist ein Schritt im Ablauf, an dem eine eingehende Aktivitätskante sich ohne Bedingungen sofort in mehrere ausgehende nebenläufige Aktivitätskanten teilt, die damit alle „aktiviert“ werden.

160

Einfaches Beispiel

Auftrag erhalten

Auftrag fertig stellen

Über NachtAuslieferung

NormaleAuslieferung

Rechnungsenden

Zahlungerhalten

Auftragabschließen

Anfangszustand

Aufspaltung

Aktivität

Entscheidung

Zusammen-führung

Synchronisation

Endzustand

[else][Eilauftrag]

Bedingung

161

Elemente

Schwimmbahnen (“swimlanes”)verdeutlichen die Verantwortlichkeiten: Organisationseinheiten (konzeptionell) Klassen (spezifizierendes, konzeptionelles

Modell)

Abteilung 1 Abteilung 2 Abteilung 3

162

UML - Aktivitätsdiagramm(Notation)

Aktivität

Aktivität1 Aktivität2

[Bedingung]

Aktivität

Kontrollfluß

Aktivität2 wird nachAbschluß von Aktivität1gestartet.

Verzweigung(-saktivität)(kann auch durch normaleAktivität dargestellt werden)

Kontrollfluß, der unter derangegebenen Bedingunggewählt wird.

Synchronisation der Kontrolle (AND)mit Synchronisationsbedingung (Join)

Aufsplitten der Kontrolle (Zulassen von Parallelität, Fork)

[Bedingung]

163

Aktivität

Aktivität wird durchgeführt,wenn über einen der eingehendenKontrollflüsse die Kontrolle ankommt(OR)

Start des Ablaufs (mit Aktivität)

Ende des Ablaufs (optional)

UML - Aktivitätsdiagramm (Notation)

164

Beispielaufgabe (Adresskartei)

Das Ziel ist die Erstellung eines Softwareprodukts, mit dem eineAdresskartei verwaltet werden kann. Aus der Namensliste wird ein Name ausgewählt, zu dem die vollständige Adresse gesuchtwird.Eine vollständige Adresse besteht aus Name, Vorname, Straßemit Hausnummer, Ort mit Postleitzahl und Telefonnummer.Zusätzlich kann ein Kommentar vermerkt werden.Es soll möglich sein, eine Adresse neu aufzunehmen, zu löschenoder zu verändern.

165

Anwendungsfall: Adresse suchen

- Es soll anhand des Namen gesucht werden- Wenn die Suche erfolgreich war, sollen die Adressdaten ausgegeben werden- War die Suche nicht erfolgreich soll eine Fehlermeldung ausgegeben werden

166

Lösung (Adresse suchen)

167

Anwendungsfall: neue Adresse aufnehmen

- Es sollen folgende Daten aufgenommen werden:* Name (Nachname, Vorname)* Adresse (Straße, Hausnummer)* Ort (Ort, PLZ)* Telefonnummer* Kommentare

- Diese Daten sollen dann gespeichert werden

168

Lösung (neue Adresse aufnehmen)

169

• Axel ist gerade aufgestanden und will etwas kreislaufsteigerndes trinken. Er möchte am liebsten einen Kaffee. Sollte kein Kaffee zur Verfügung stehen, dann nimmt er auch mit einer Dose Cola vorlieb. Ist weder Kaffee noch Cola im Haus, legt er sich wieder hin.

• Wenn er eine Dose Cola findet, dann nimmt er sie und trinkt sie. (anschließend geht er trotzdem wieder ins Bett!)

• Hat er aber seinen heißgeliebten Kaffee gefunden, macht er sich auch gleich an die Zubereitung des Heißgetränks. In Windeseile (fast gleichzeitig) füllt er den Automaten mit Wasser und das Pulver in den Filter. Nebenbei nimmt er sich noch seine rosa Henkeltasse und steckt den Filter in die Maschine.

• Hat er dies alles erledigt, dann schaltet er die Kaffeemaschine ein und harrt der Dinge. Der Kaffee kocht.

• Wenn der Kaffee fertig gebrüht ist, schenkt er sich eine Tasse ein.

• Jetzt kann er trinken (und erholt sich von der Anstrengung im Bett).

• (nach OMG Spec. 1.4)

170

Lösung der Übungsaufgabe

171

© H. Balzert 2001

Aktivitätsdiagramm

172

Quelle: http://www.informatik.fh-wiesbaden.de/~dreher/lv/SwtNeu/Folien/SWTneu_5_5-5_7.PDF, letzte Seite173

OMG Spec. 1.4174

OMG Spec. 1.4175

Checkliste für Zustandsfindung

Identifikation relevanter Ereignisse Zeitlich gruppieren

176

Interaktionsdiagramme

Objektorientierte Darstellung eines Prozesses Objekte aus dem Klassendiagramm erledigen

zusammen eine Aufgabe („Kollaboration“) Dabei tauschen sie Nachrichten aus (Requests,

Methodenaufrufe) („Kommunikation“) Die Interaktionsdiagramme stellen die zeitlichen

Abfolge dieser Kommunikation dar Sequenzdiagramm: Nachrichten auf der Zeitachse Kommunikations-/Kollaborationsdiagramm:

Nummerierung der Nachrichten nach ihrer zeitlichen Abfolge

177

Kommunikations-/Kollaborationsdiagramm

Statische Sicht auf die beteiligten Objekte wie im Klassendiagramm

Verschiedene Notationselemente zur Charakterisierung der Nachrichten

178

Aus: 179

Arten von Nachrichten

Aufruf: Die Nachricht besteht im synchronen Aufruf einer Operation ähnlich dem Aufruf eines Unterprogramms.

Flacher Kontrollfluss (flat flowof control): Diese Nachrichten sind meist asynchron. Wenn ausschließlich diese Pfeile verwendet werden, können sie sowohl synchrone als auch asynchrone Nachrichten bedeuten.

Asynchron: Der Sender schickt eine Nachricht an den Empfänger, kümmert sich aber nicht weiter darum. Z.B. Sie senden ein E-Mail an einen Freund und arbeiten danach weiter.

182


Iteration: Wiederholung der Nachricht wir notiert durch einen Stern „*“ ggf. ergänzt durch eine Abbruchbedingung in eckigen Klammern „[ ]“ . Z.B. das Eintippen einer PIN oder einer Telefonnummer. Möglich ist auch ein einer for-Anweisung ähnelnde Schreibweise wie „[i=1..n]“;

Rückgabenachricht bzw . - wert: wird oft in Kombination mit synchronen Aufrufen verwendet.

183


Geschachtelte Nachrichten können durch Dezimalziffern dargestellt werden. Z.B. wird 2.1 innerhalb der von 2 ausgelösten Prozedur versendet.

Parallele Nachrichten können durch gleiche Zahlen oder angehängte Buchstaben beschreiben werden. Z.B. 2 Nachrichten mit Nummerierung 4 oder 4a und 4b.

184

Objektbezeichnungen

C Anonymes Objekt der Klasse C /R Anonymes Objekt in der Rolle

R O/R Ein Objekt O in der Rolle R O:C Ein Objekt O der Klasse C O/R:C Ein Objekt O der Klasse C in

der Rolle R O Ein Objekt O Aus: Kahlbrandt, Software Engineering

185

Ein Kollaborationsdiagramm kann sowohl „permanente“ Objekte als auch „temporäre“ Objekte beinhalten. Erstere sind Objekte, welche bestimmten Beziehungen entsprechen. Letztere sind Objekte, welche lokalen Variablen entsprechen.

186

Schlüsselwörter in dieser Diagrammart sind weiterhin: new, destroy und transistent. Diese werden innerhalb des Diagramms in „{ }“ notiert.

Das „new“ bedeutet die Erstellung einer Instanz, Das Schlüsselwort „destroy“ die Löschung einer

Instanz. „transistent“ deutet an, dass ein Objekt innerhalb

einer Interaktion erzeugt, jedoch auch wieder zerstört wird.

187

Für den Fall, dass eine Nachricht ein Objekt aus einer Menge auswählt oder eine Menge von Objekten nach einem geeigneten Empfänger durchsucht, kann ein Multiobjektsymbol verwendet werden. Das verwendete Objekt wird wie folgt dargestellt:

: Class : Class

188

Ein Beispiel für die Anwendung eines solchen Multiobjektsymbols ist z.B. das Beenden einer Anwendung in Windows. Das Hauptfenster schickt hierbei typischer Weise eine Nachricht (CanClose()) an alle Child-Fenster.

189

Elemente eines Kollaborationsdiagramms

Objekte: Sie werden durch ein Rechteck dargestellt, in welchen der Objektname eingetragen ist.

Object : Class

190


Verbindungen zwischen Objekten

Object : Class Object : Class

191


Nachrichten: Diese werden auf den kleinen Pfeilen über oder unter den Verbindungen notiert. Allgemeiner Nachrichtenaufbau:

[Vorgängerbedingung]Nummerierung:[Antwort:=]Nachrichtenname(Argumentenliste)

Object : Class Object : Class

192

Beispiel: Ablauf eines allgemeinen Geschäftsauftrages

Im Folgenden soll der Ablauf eines allgemeinen Geschäftsauftrages als Beispiel für ein Kollaborationsdiagramm dienen.

Die Spezifikation des Auftrages schaut wie folgt aus: Der Kunde erteilt den Auftrag dem Verkäufer. Der Verkäufer stellt daraufhin eine Bonitätsanfrage an das Controlling Das Controlling checkt nun die Bonität und sendet das Ergebnis zurück an

den Verkäufer. Nun kann der Verkäufer dem Kunden die Auftragsbestätigung zubringen. Gleichzeitig erzeugt der Verkäufer im System einen neuen Auftrag. Der Auftrag wir ausgeführt und an den Kunden geliefert Im weiteren Verlauf erhält der Kunde die Rechnung. Daraufhin überweist der Kunde den Rechnungsbetrag an das Controlling

des Unternehmens. Mit dem Zahlungseingang des Kunden wird der Auftrag vom Controlling

wieder im System gelöscht. (Beispiel Aus: Kahlbrandt, Software Engineering)

193

Beispiel Aus: Kahlbrandt, Software Engineering194

Beispiel. Handytelefonat

Use Case: Tätige Anruf Der Benutzer drückt auf die Handytasten um die Telefonnummer

einzugeben. Zu jeder eingegebenen Ziffer wird ein entsprechender Ton durch den

Dialer erzeugt und über den Lautsprecher ausgegeben. Jede eingegebene Ziffer wird an die bisher gewählten Ziffern im

Display angehängt. Der Benutzer drückt auf die „Waehlen“-Taste. Der Verbindungschip baut eine Verbindung zum Gesprächspartner

auf. Auf dem Display wird angezeigt, wie lange das Gespräch dauert.

Nach: http://www.objectmentor.com/resources/articles/umlCollaborationDiagrams.pdf

195

http://www.objectmentor.com/resources/articles/umlCollaborationDiagrams.pdf


Nach:http://www.objectmentor.com/resources/articles/umlCollaborationDiagrams.pdf

Handy

Dialer

+Nummer: String

+get(input: integer)+update_nummer(input: integer)

Taste

+wert: Integer

Verbindungschip

+verbinde(nummer: String)

Mikrofon

Display

+Verbindungszeit: String+aktuelleAnzeige: String

+zeige_verbindungszeit()+add_to_anzeige(input: integer)

Lautsprecher

+ton_ausgeben(input: integer)

Zifferntaste

196



: Zifferntaste

: Verbindungschip

: Dialer

1 : get(input)

2 : update_nummer(input)

: Lautsprecher

3 : ton_ausgeben(input)

: Display

4 : add_to_anzeige(input)

6 : verbinde(nummer)

7 : zeige_verbindungszeit()

Waehlen : Taste

5 : get(input)

197

: Zifferntaste : Verbindungschip : Dialer : Lautsprecher : Display Waehlen : Taste

1 : get(input)

2 : update_nummer(input)

3 : ton_ausgeben(input)

4 : add_to_anzeige(input)

5 : get(input)

6 : verbinde(nummer)

7 : zeige_verbindungszeit()

198

Sequenzdiagramm

199

Use-Case Beschreibung 1.1.2. Anwendungsfall: Buchungsaufträge erstellen Beschreibung Kurzbeschreibung:

Die Informationen erlauben es dem Use Case Buchungsaufträge ausführen, die buchhalterischen Schritte durchzuführen. Dabei werden nicht nur primäre Buchungssätze erzeugt, sondern auch aus Fachlichkeit der Finanzbuchhaltung weitere Buchungen generiert (z.B. Buchungen auf Kapitalumsatzkonten bei gesellschaftsübergreifenden Geschäftsvorfällen). Jede Buchung wird im Journal als Vollbuchung hinterlegt (Soll- und Habenkonto). Nach jeder Buchung wird (automatisch) eine Buchungskontrolle durchgeführt.

Auslöser:Aus dem Anwendungs Use Case (z.B. ZKK-Aufträge bearbeiten) wird jeder einzelne Buchungsauftrag erzeugt.

Vorbedingung:Der Buchungsauftraggeber und der -auftrag sind korrekt.

Ergebnis:- Auftrag ist gebucht- Journal ist fortgeschrieben

Szenarienbeschreibung:1. Kontierungen feststellen2. Buchungsperiode bestimmen3. Buchungen erzeugen (1-n)4. Journal bedienen5. Buchungskontrolle

Aktor:System

Variantenbeschreibung:- keine -

202

Zustandsdiagramme

204

Systembeschreibende Diagramme

– Paketdiagramm– Komponentendiagramm– Verteilungsdiagramm

205

Paketdiagramm

• Das Paketdiagramm wird zur Strukturierung des Systems in überschaubare Einheiten verwendet.

206

Notationselemente eines Paketdiagramms• Paket

– Ein Paket fasst Modellelemente sinnvoll zusammen und definiert einen Namensraum für die enthaltenen Elemente.

{import Packet B :: Element A}

<<import>>

Paket-Import

Importiertes PaketImportierendes Paket

Paket A Paket B

+ Element A

Paket A

Alternative Darstellung des Paket-Imports:

207

Paket-Import

• Der Paket-Import wird verwendet, wenn ein Paket (importierendes Paket) alle Namen öffentlicher Elemente eines anderen Paketes (importiertes Paket) als öffentlich erhalten soll.

{import Packet B :: Element A}

<<import>>

Paket-Import

Importiertes PaketImportierendes Paket

Paket A Paket B

+ Element A

Paket A

Alternative Darstellung des Paket-Imports:

208

Beispiel für einen Paket-Import

• Im Paket Mathematik erweitert – kann durch den Paket-Import - die Klasse Real direkt über den unqualifizierten Namen angesprochen werden.

Real

- genauigkeit

+ quadratwurzelziehen()

<<import>>

Mathematik Mathematik erweitert

209

Paket-Access : Paket-Import ohne Weitergabemöglichkeit• Der Paket-Access kennzeichnet einen privaten Import von

öffentlichen Elementen; d.h. sie werden im importierenden Paket als privat hinzugefügt.

Mit <<access>> importierte Elemente können nicht an dritte Pakete weitergegeben werden.

<<access>>

Paket-AccesPaket A Paket B

+ Element A

{access Packet B :: Element A}

Paket A

Alternative Darstellung des Paket-Acceses:

210

Administrator- name: String- geburtsdatum: Date

<<import >>

<<access>>

<<access>>

Geldautomatensystem

Geldautomat- automatennummer: int- umsatz: float+ karte einziehen()+ eingabGeheimzahl(int pin)+ transaktionstarten()+ seriennummereinlesen() + karteausgeben()+ geldausgeben()

Bankkundenverwaltung

Privatkunde- vorname: String- nachname: String- geburtsdatum: Date

Geschäftskunde- firmenname: String

Kontoverwaltung

Umsatz- datum: Date- nummer: int- betrag: float- umsatzweck: String

Datenverwaltung

Datenbank Datenpflege

Bank- bankleitzahl: int- name: String- ort: String

Girokonto- sollzins: float- dispokredit: float+ auszahlen (betrag: float) + zinsgutschreiben()+ sollzinsabbuchen()

Sparkonto- höchstbetrag: float+ auszahlen (betrag: float) + zinsgutschreiben()

211

Komponentendiagramm

• Sie geben Auskunft darüber welche Teile eines Systems zusammenarbeiten. Mit Hilfe von Komponentendiagrammen werden Komponenten und deren Schnittstellen oder aber Ports dargestellt. Des Weiteren zeigen sie auf, wie die einzelnen Komponenten über Abhängigkeits-beziehungen sowie Konnektoren miteinander verbunden sind.

212

Stereotyp der Komponente

Komponentensymbol

Komponente

<<component>> Komponente

213

Beispiel

214

Black-Box-Sicht

• Die Black-Box-Sicht zeigt den Rand und die Schnittstellen, die die Komponente von außen anbietet bzw. von anderen Komponenten bezogen werden müssen. Für die Notation von Schnittstellen, können graphisch alle Möglichkeiten genutzt werden.

<<provided interface>> SortierterZugriff WahlfreierZugriff<<required interfaces>> Speichermedium

<<component>> Teilnehmerverwaltung

215

White-Box-Sicht

• Die White-Box-Sicht zeigt die innere Struktur einer Komponente. Diese Struktur kann aus Teilkomponenten bestehen.

<<provided interface>> SortierterZugriff WahlfreierZugriff<<required interfaces>> Speichermedium<<realizations>> Teilnehmer Verwaltungsmetadaten<<artifacts>> teilnehmer.jar


216

Komponentensymbole in Rational Rose

• Ausführbare:

• Library:

• Table:

• File:

• Dokument:

Table<<Database>>

Ausführbare Komponente

<<EXE>>

Table

Dokument<<Document>>

Library<<DLL>>

Source-Code<<File>>

217

– Executable (ausführbar)Komponente, die auf einem Knoten ausgeführt werden kann

– Library (Bibliothek)statische oder dynamische Objektbibliothek

– Table (Tabelle)Komponente, die eine Datenbanktabelle repräsentiert

– File (Datei)Komponente, die ein Dokument mit Sourcecode oder Daten repräsentiert

– Document (Dokument)Komponente, die ein Dokument repräsentiert

218

Beispiele für Komponenten

• Exe-Dateien

• Dll Programmbibliotheken

• Java-Dateien

• Datenbanktabellen

• ...

219

Weitere Stereotypen

• <<script>> (Script-Datei)

• <<document>> (Dokument)

• <<executable>> (ausführbare Datei)

• <<file>> (nicht näher spezifizierte Datei)

• <<library>> (Bibliotheksdatei)

• <<source>> (Quelltext)

220

Weitere Stereotypen

• <<implement>>: Eine Komponente, die mit <<implement>> gekennzeichnet ist, realisiert eine Komponente, die mit dem Stereotypen <<specification>> versehen ist.

• <<service>>: Bei einer mit dem Stereotyp <<service>> gekennzeichneten Komponente handelt es sich um eine zustandslose funktionale Komponente, welche beispielsweise einen Wert berechnet. Sie stellt somit anderen Komponenten Dienste zur Verfügung.

• <<specification>>: Kennzeichnet eine Komponente, welche bereitgestellte und benötigte Schnittstellen definiert, aber keine physikalische Implementierung für diese Schnittstellen spezifiziert. Die Realisierung erfolgt durch eine <<implement>>-Komponente

• <<subsystem>>: Einheiten großer Systeme werden alternativ zu <<component>> mit dem Stereotypen <<subsystem>> gekennzeichnet)

221

benötige Schnittstelle

realisierte Schnittstelle

Klasse BKlasse A

Schnittstellen und Ports

222

Delegationskonnektor

• Wird für die Verbindung einer externen Schnittstelle oder eines Ports und den inneren Bestandteilen einer Komponente verwendet. Er wird mit dem Stereotypen <<delegate>> gekennzeichnet.

Bauteil-Konnektor

Delegationskonnektor

<<delegate>>

<<component>> Komponente A

<<subsystem>> Subsystem

<<component>> Komponente B

223

Kompositionskonnektor

• Ein Kompositonskonnektor zeigt die Verbindung zwischen angebotenen und benutzten Schnittstellen bzw. Ports. Der Port der einen Komponente muss eine Schnittstelle anbieten, die der Port der anderen Komponente benötigt.

224

Manifest-Beziehung

• Mittels einer „Manifest-Beziehung“ - die durch den Stereotypen <<manifest>> gekennzeichnet ist - wird es möglich, Artefakte den Komponenten - die sie physisch realisieren - zuzuordnen

Manifest-Beziehung

<<manifest>>

WahlfreierZugriff

Speichermedium

SortierterZugriff


<<artifact>> teilnehmer.jar

225

<<manifest>> <<component>> Konto-DBMS

Einzahlung

Auszahlung

Speichermedium

<<component>>Kontoverwaltung

<<component>>Geldautomaten-GUI

<<artifact>> Oracle 10g

226

komplexer Port

ExternesDisplayzeigt Zeit

Display

Wecker

UhrzeitStandardFunksignal

227

Substituierende Komponenten

• Wenn Schnittstellen von zwei Komponenten übereinstimmen, dann ist es möglich, die Komponenten untereinander zu tauschen. Die substituierende Komponente kann ihrerseits zusätzliche Schnittstellen anbieten, die die ersetzte Komponente nicht hatte

Zusätzliche Schnittstelle

Schnittstelle B Schnittstelle ASchnittstelle A

Ersetzte KomponenteSubstituierende Komponente

<<substitute>><<component>> Komponente A

<<component>> Komponente B

228

Kombination

• Schnittstellen können mit Hilfe von Ports organisiert werden

WahlfreierZugriff

Speichermedium

SortierterZugriff


229

Verteilungsdiagramm

• Spezifizieren der physischen Hard- und Spezifizieren der physischen Hard- und SoftwareumgebungSoftwareumgebung

• Wird in der Entwurf/Design-Phase erstelltWird in der Entwurf/Design-Phase erstellt

• Auf seiner Basis Entscheidung über:Auf seiner Basis Entscheidung über:

– Hardware- und SoftwarekomponentenHardware- und Softwarekomponenten

– Komponentenverteilung (Software)Komponentenverteilung (Software)

– Kommunikationsbeziehungen zwischen KnotenKommunikationsbeziehungen zwischen Knoten

230

KnotenKnoten

Stereotyp des Knoten

Name des KnotensKnoten

<<device>>Server

232

AttributeAttribute

Attributname Attributtyp Vorgabewert

<<application server>>Applikationsserver

+ prozessor: GHz = 3.2+ RAM GByte = 16+ Festplatte: GByte = 600

233

OperationenOperationen

Sichtbarkeit Operation

Attribute

Operationen

<<execution environment>>Linux

+ distribution = SuSE 10

+ boot() + shutdown()

234

HierarchieHierarchie von Knotenvon Knoten

<<application server >>Applikationsserver

<<execution environment>>Tomcat

<<artifact>>PdfErzeuger.class

235

Deploy-AbhängigkeitDeploy-Abhängigkeit

<<artifact>>PdfErzeuger.class

Ausführungsumgebung

Artefact

Deploy-Abhängigkeit

<<deploy>>



236

EinsatzspezifikationEinsatzspezifikation

<<artefact>>erzeugePdf.jar

<<deployment spec>>Web.xml

+ servlet-name: = erzeugePdf+ servlet-class: = Hauptklasse

<<deploy>> <<execution environment>>Tomcat

237

Deployment-Specs - Einsatz- bzw. Verteilungsspezifikationen

238

Einsatzspezifikation innerhalb Einsatzspezifikation innerhalb eines Knotenseines Knotens


<<deployment spec>>web.xml+ servlet-name: = erzeugePdf+ servlet-class: = Hauptklasse

<<artifact>>erzeugePdf.jar

Einsatzspezifikation

239

Einsatzspezifikation innerhalb Einsatzspezifikation innerhalb eines Artefaktseines Artefakts


<<artifact>>erzeugePdf.jar{servlet-name: = erzeugePdfServlet-class: = Hauptklasse}

240

KommunikationspfadKommunikationspfad

+Server

11..*

+Client<<internet>>

Kommunikationspfad Multiplizität

KommunikationskanalRolle

<<client PC>>PC


241

Stereotypen

• Mit Hilfe von Stereotypen können auch Knoten als sog spezielle Knoten definiert werden. Die beiden wichtigsten Stereotype sind <<device>> und <<execution Environment>>.

242

<<device>>

• Mit <<device>> gekennzeichnete Knoten repräsentieren im Verteilungsdiagramm die Hardware des Systems, z.B. einen Rechner.

243

<<execution Environment>>

• Mit <<execution Environment>> wird dagegen eine Ausführungsumgebung bezeichnet. Sie wird von bestimmten Softwarekomponenten zur Ausführung benötigt. Meist ist die Ausführungsumgebung Teil eines Hardware-Knotens. Diese Elemente werden dann als verschachtelte Knoten bezeichnet. Die rechte Abbildung zeigt z.B. einen Rechner auf dem unter anderem eine Ausführungsumgebung für Java-Anwendungen installiert ist.

244

StereotypenStereotypen

• StereotypenStereotypen– <<device>><<device>>– <<execution environment>><<execution environment>>– <<application server>><<application server>>– <<client workstation>><<client workstation>>– <<mobile device>><<mobile device>>– <<artifact>><<artifact>>– Definition weiterer Stereotypen möglich!Definition weiterer Stereotypen möglich!

245

Quelle: http://casablanca.informatik.hu-berlin.de/database/modsoft/VL/V16-MODSOFT-V.Struktur.pdf

246

Quelle: http://se.cs.uni-magdeburg.de/tutorial/UML2/Verteilungsdiagramm.htm 247

Verteilungsdiagramme als Erweiterung anderer UML-Diagrammtypen

Quelle: http://www.die.informatik.uni-siegen.de/pgleo/handbuch/A_UML.html

248

Quelle: http://www3.informatik.uni-erlangen.de/Lehre/UMLEmbSys/WS2002/muster.gif249

Verteilungsbeziehung

250

Häufig gemachte FehlerHäufig gemachte Fehler

253

Häufig gemachte FehlerHäufig gemachte Fehler

(A): Richtung der <<deploy>> Abhängigkeit ist falsch

B: (B): Abhängigkeit fehlt

(C): Mehrfachknoten

(D): Stereotyp fehlt

(E): Kommunikationskanal fehlt

254

Übungsaufgaben zu Komponenten- und Einsatzdiagrammen

• In den zwei nachfolgenden Aufgaben soll eine Softwareinstallation für die Firma Autos & Co erstellt werden. Sie liefern die Verkaufssoftware AutoKauf aus. Diese besteht aus einer zentralen Programmdatei, einer Hilfedatei, einer Schnittstelle zu S & AP und zu der Oracle-Datenbank. Da sie in Visual C++ 6.0 erstellt wurde wird sie mit der Programmbibliothek MFC40.DLL ausgeliefert und einer readme.txt installiert.

• • Identifizieren Sie die einzelnen Komponenten und Schnittstellen der Software

AutoKauf.

• Erstellen Sie ein Komponentendiagramm für die Verkaufssoftware!

255

Aufgabe 1• Es soll auf zwei Servern getrennt, die Finanzbuchhaltungssoftware

"Schrecken, Angst & Panik" (S & AP) und eine Oracle-Datenbank laufen. Für die Verkäufer und den Chef sind drei Client-Rechner vorhanden, mit denen sie Modelle, Zubehör usw. abfragen können. Diese Rechner und die Kasse greifen auf den S & AP-Server zu. Die bei Server sind untereinander über ein LAN verbunden. Die Clients sind untereinander über ein WLAN (Access-Point) mit den S & AP-Server verbunden. Die beiden Server sind untereinander über einen LAN-Router verbunden, der PC des Administrators (Chef) hat als einziger Client ebenfalls Zugriff zu diesen Netz.

•

• Identifizieren Sie die einzelnen Knoten des Einsatzdiagramms.

• Erstellen Sie ein Verteilungsdiagramm für die Rechnerstruktur in der Autofirma!

256

Aufgabe 2• Sie liefern die Verkaufssoftware AutoKauf aus. Diese

besteht aus einer zentralen Programmdatei, einer Hilfedatei, einer Schnittstelle zu S & AP und zu der Oracle-Datenbank. Da sie in Visual C++ 6.0 erstellt wurde wird sie mit der Programmbibliothek MFC40.DLL ausgeliefert und einer readme.txt installiert.

•

• Identifizieren Sie die einzelnen Komponenten und Schnittstellen der Software AutoKauf.

• Erstellen Sie ein Komponentendiagramm für die Verkaufssoftware!

• 257

Ein „realistisches“ Beispiel

260

Die Object Constraint Language

267

• Rational Rose Übungsanleitung

• Use Case Diagramm aufrufen• Anmerkung: falsche Diagrammteile mit Edit – Delete from Model (CTRL+D) löschen• Rechter Klick, um den Use Case (Use Case View) im Browser auszuwählen und das

Shortcutmenü sichtbar zu machen.• Auswahl von New: Sequence Diagram. Ein unbenanntes Sequenzdiagramm wird dem

Browser hinzugefügt. • Während das Sequenzdiagramm ausgewählt ist, Eingabe eines Namens für das

Sequenzdiagramm: „Mitarbeiter hinzufügen“. • Doppelklick auf das Sequenzdiagramm im Browser, um das Diagramm zu öffnen. • Klick, um den Akteur „Planer'' im Browser auszuwählen. • Ziehen des Akteurs „Planer'' in das Sequenzdiagramm. • Klick, um das Objekticon in der Werkzeugleiste auszuwählen. • Klick auf das Sequenzdiagrammfenster, um das Objekt zu platzieren. • Während das Objekt ausgewählt ist, Eingabe des Objektnamens. • Wiederholen der vorangegangenen Schritte für jedes Objekt im Szenario. • Klick, um das Objektbotschaftsicon (message icon) in der Werkzeugleiste auszuwählen.

268

• Klick auf den botschaftssendenden Akteur „Planer'' oder das botschaftssendende Objekt und ziehen der Botschaftslinie zu dem empfangenden Akteur oder dem empfangenden Objekt.

• Während die Botschaftslinie ausgewählt ist, Eingabe des Botschaftsnamens.

• Falls nötig weitere Informationen zu der Botschaftslinie im Dialogfenster kommentieren.

• Wiederholen der Schritte14 bis 17 für jede Botschaft im Szenario.

• Gehen Sie mit der Maus auf das Sequenzdiagramm „Mitarbeiter hinzufügen“ und aktivieren Sie es.

• Betätigen Sie die Funktionstaste F5. Es wird automatisch ein Zusammenspieldiagramm „Mitarbeiter hinzufügen“ generiert.

• Wenn die Elemente übereinander erzeugt wurden (was i.A. der Fall sein wird), ziehen Sie sie auseinander.

• Tipp: Für den Fall, dass Sie es bei Ihrer Arbeit angenehmer finden, zuerst das Zusammenspieldiagramm zu erstellen, können Sie daraus ebenfalls mittels der Taste F5 ein Sequenzdiagramm automatisch erzeugen

269

Der Begriff OCL Entwicklung Begriffsabgrenzung Constraints

Definition Constrainttypen

Beispiel an einem Klassendiagramm

270

Object Constraint Language

Konstrukte der OCL Das Konstrukt „Self“ Konstrukttypen und -operationen

Boolean Type Integer Type Real Type String Type Kollektion Type

Typen: Set, Bag, Sequence Operationen zu den Typen Beispiele

271

Nutzerdefinierte Typen Typkonformität Übung

272

ursprünglich entwickelt von IBM (1995)

zur Verwendung als „Business Engineering Language“ entworfen

später als formale Spezifikationssprache in die UML übernommen (1997 UML 1.1)

OCL dient zur Spezifikation von WFRs (Wellformedness Rules) von UML-Modellen (auf Metamodellebene)

Auch in UML 2.0 Standard

273

Object steht für eine Komponente eines beliebigen Systems, das genauer spezifiziert, definiert oder beschrieben wird.

Constraint steht für eine Begrenzung oder Einschränkung, die maximale oder minimale Werte annehmen kann.

Language steht für eine auf jede Implementierung anwendbare wenig-formale Sprache.

274

Object Constraint Language (OCL) ist Teil der Unified Modeling Language (UML)

– Standardisierte, deklarative, seiteneffektfreie und formale

Sprache für die Definition von Constraints auf UML-Modellen,

– Fügt graphischen (UML-) Modellen präzisierte Semantik hinzu,

275

Beispiel - Klassendiagramm

276

Constraints

sind immer mit einem objektorientier-ten Modell verbunden (meist UML),

können in diesen an verschiedensten Stellen eingesetzt werden,

schränken den Wertebereich einer Variablen ein,

helfen, Programmierfehler leichter zu erkennen.

278

Definition:

„Ein Constraint (Eine Einschränkung) ist ein Prädikat, dessen Wert wahr oder falsch ist. Boolesche Ausdrücke sind … Einschränk- ungen. …OCL erlaubt die formale Spezifikation von Einschränkungen für einzelne Modellelemente (z.B. Attribute, Operationen, Klassen) sowie für Gruppen von Modellelementen (z.B. Assoziationen)“

Brügge, B., Dutoit, A.H.: Objektorientierte Softwaretechnik mit UML, Entwurfsmustern und Java. PEARSON Studium, 2004

279

Erläuterte Constrainttypen

Invarianten

Pre- & Postconditions

Initial & Derived Value

Package Context

Operation Body Expression

280

Invarianten

Definition:Eine Invariante ist ein Constraint, das für

ein Objekt während seiner ganzen Lebenszeit wahr sein sollte.

Syntax:

context Typenameinv: Ausdruck

281

Invarianten

Beispiel:

Die Kunden müssen über 18 Jahre alt sein.

self.age >= 18

context: Client inv: self.age >= 18

context c: Client inv: c.age >= 18

context c: Client inv overAge: c.age >= 18

282

Preconditions

Definition: Eine Precondition ist ein Boolescher Ausdruck, der zum Zeitpunkt des

Beginns der Ausführung der zugehörigen

Operation wahr sein muss.

Syntax:

context Typename :: operationName (param1: Type1, …) : ReturnType pre: param1 > …

283

Preconditions• Beispiel:

• Das Einkommen eines Kunden muss vor einem Leihauftrag mehr als 1500 € sein (als Sicherheit).

• context Client :: income (d: Date) : Integer

• pre: income > 1500

284

Postconditions

Definition: Eine Postcondition ist ein Boolescher Ausdruck, der unmittelbar nach der Ausführung der zugehörigen Operation wahr sein muss.

Syntax:

context Typename :: operationName (param1: Type1, …) : ReturnType post: result = …

285

Postconditions

Beispiel:

Das Einkommen eines Kunden darf nach der Operation nicht weniger als 1000 € betragen (bei Ratenzahlung eine mögliche Postcondition).

context Client :: income (d: Date) : Integer

post: result >= 1000

286

Initial & Derived Values

mit derive kann man den Wert eines abgeleiteten Attributes durch eine Formelfestlegen; bei jedem lesenden Zugriff auf das Attribut wird die Formel berechnet

mit init kann man einen initialen Wert für ein Attribut festlegen, der späterdurch Zuweisungen überschrieben werden kann

Syntax

context Typename :: attributeName: Type init: --Ausdruck

context Typename :: assocRoleName: Type derive: --Ausdruck

287

Initial & Derived Values

Beispiel:

Für ein neues Auto wird ein Zehntel des Neupreises als Kaution verlangt, für ein 10 Jahre altes Auto nichts.

context RentalContract :: deposit() : Integer init: motorVehicle.price * (10 - motorVehicle.age)

/ 100 derive: if motorVehicle.age < 10 then motorVehicle.price * (10 -

motorVehicle.age) / 100 else 0 endif

288

Package Context wird benutzt, wenn Kontext-

deklaration nicht präzise genug ist,

kann in gesonderte Datei gespeichert werden.

Syntax:

package Package::SubPackage context X inv: …Invariante… context X ::operationName(…) pre: …Precondition… endpackage

289

Operation Body Expression Wird benutzt, um das Ergebnis

einer Abfrageoperation anzuzeigen,

Der Ausdruck muss dem Ergebnistyp (result) einer Operation entsprechen,

Kann mit Pre- und Postconditions gemischt werden.

Syntax:

context Typename::operationName(param1: Type1, …): ReturnType

body: --Ausdruck

290

„self“

bezieht sich explizit auf das betrachtete Objekt der ausgewählten Klasse,

wird benutzt, wenn der Kontext nicht eindeutig ist.

Beispiel:

context Client Inv: self.age >= 18

291

Konstrukte der OCL

• Jedes Objekt hat einen Typ, der die auf das Objekt anwendbaren Operationen definiert.

• Es gibt zwei verschiedene Typenarten:– Vordefinierte Typen

• Boolean• Integer• Real• String• Collection

– Set– Bag– Sequence– Collection

– Benutzerdefinierte Typen

292

Konstrukte der OCL

Operation Notation Ergebnistyp

Oder a or b Boolean

Und a and b Boolean

Exklusives oder a xor b Boolean

Negation not a Boolean

Gleich a = b Boolean

Ungleich a <> b Boolean

implies a implies b Boolean

if then else if a then b else b ́endif Typ von b und b´

Boolean Type

Werte: true, false

Operationen:

293

Konstrukte der OCL

Boolean Type – implies

besteht aus zwei boolschen Operationen

Gesamter Ausdruck ergibt true, wenn Ergebnis des ersten sowie des zweiten boolschen Ausdrucks true ist Ergebnis des ersten Ausdrucks false ist

Beispiel für implies:context ClientisMale implies title = ‘Mr.‘

294

Konstrukte der OCL

• Integer Type

• Wertebereich:

• Menge der ganzen Zahlen ohne Obergrenze

• Operationen:– Addition, Subtraktion, Multiplikation, Division– Modulus, Integer Division, Absolutwert,

Minimum.295

Konstrukte der OCL

• Real Type

• Wertebereich:• Gleitkommazahlen ohne Obergrenze

• Operationen:– Addition, Subtraktion, Multiplikation, Division

• Rundungsoperationen für Real:– Abrunden auf den nächstgelegenen Integer-Wert

Bsp.: (3.6).floor ergibt 3– Runden auf die nächste Integer-Zahl

Bsp.: (3.6).round ergibt 4

296

Operationen für integer und real

Operation Notation Ergebnistyp

Gleich a = b Boolean

Ungleich a <> b Boolean

Kleiner a < b Boolean

Größer a > b Boolean

Kleiner-gleich a <= b Boolean

Größer-gleich a >= b Boolean

Plus a + b Integer or Real

Minus a – b Integer or Real

Multiplikation a * b Integer or Real

Division a / b Real

Modulus a.mod(b) Integer

Integer Division a.div(b) Integer

Absolutwert a.abs Integer or Real

Minimum von a und b a.min(b) Integer or Real

Runden a.round Integer

Abrunden a.floor Integer

297

String Type

Notation:

Strings in halben Anführungszeichen

Operationen für Strings:

Verbindung: string.concat(string)‘Willy‘.concat(‘und

Harry‘) = ‘Willy und Harry‘Länge:

string.size ‘Willy‘.size = 5

Substring:string.substring(int,int) ‘Willy und

Harry‘.substring(11,15) = ‘Harry‘

298

Konstrukte der OCL

Operationen für Strings:

Kleinbuchstaben: string.toLower‘Willy‘.toLower = ‘willy‘

Großbuchstaben: string.toUpper‘Willy‘.toUpper = ‘WILLY‘

Gleichheit: string1 = string2(‘Willy‘=‘Harry‘) = false

Ungleichheit: string1 <> string2(‘Willy‘<>‘Harry‘) = true

299

Konstrukte der OCL

• Collection Type

• vier vordefinierte Kollektionstypen– konkrete Typen: Set, Bag, Sequence– abstrakter Typ: Collection

• Notation: – Elemente in geschwungenen Klammern – konkreter Typ vor der Klammer

300

Konstrukte der OCL

• Collection Type

• Set: keine doppelten Elementez.B.: Set{1,3,5,7} oder Set{‘Apfel‘,‘Birne‘}

• Bag: Mehrfachelemente möglich; übliches Ergebnis bei der Kombination von Navigationen z.B.: Bag{1,3,5,7,1,5}

• Sequence: wie Bag; Elemente sind nach Sequenznummer geordnetz.B.: Sequence{1,3,5,7,1} und Sequence{3,1,5,7,1} entsprechen sich nicht

301

Konstrukte der OCL

• Collection Type

• alle Operationen für Kollektionen werden in Pfeil-Notation geschrieben

Sequence{derive: motorVehicle -> size()}

• Kollektionen werden automatisch zusammengefaßt

Set{Set{1,2},Set{3,4},Set{5,6}} • = • Set{1,2,3,4,5,6}

302

Konstrukte der OCL

• Collection TypeOperation Beschreibung

size Die Zahl der Elemente in der Kollektion.

count( object ) Die Anzahl, wie oft object in der Kollektion vorkommt.

includes( object ) True, wenn das Objekt ein Element der Kollektion ist.

includesAll( collection ) True, wenn alle Elemente des Parameters collection zur Kollektion gehören.

isEmpty True, wenn die Kollektion keine Elemente enthält.

notEmpty True, wenn die Kollektion ein oder mehrere Elemente enthält.

iterate( expression ) Ein Ausdruck wird für jedes Element der Kollektion ausgewertet. Der Ergebnis Typ hängt von dem Ausdruck ab.

sum() Die Addition aller Elemente der Kollektion. Die Elemente müssen einem Typ zugehörig sein, der Addition ermöglicht( z.B. Real, Integer ).

exists( expression ) True, wenn expression für mindestens ein Element der Kollektion true ist.

forAll( expression ) True, wenn expression für alle Elemente true ist.

Collection Type - Operationen

303

Operation Beschreibung

size Die Zahl der Elemente in der Kollektion.

count( object ) Die Anzahl, wie oft object in der Kollektion vorkommt.

includes( object ) True, wenn das Objekt ein Element der Kollektion ist.

includesAll( collection ) True, wenn alle Elemente des Parameters collection zur Kollektion gehören.

isEmpty True, wenn die Kollektion keine Elemente enthält.

notEmpty True, wenn die Kollektion ein oder mehrere Elemente enthält.

iterate( expression ) Ein Ausdruck wird für jedes Element der Kollektion ausgewertet. Der Ergebnis Typ hängt von dem Ausdruck ab.

sum() Die Addition aller Elemente der Kollektion. Die Elemente müssen einem Typ zugehörig sein, der Addition ermöglicht( z.B. Real, Integer ).

exists( expression ) True, wenn expression für mindestens ein Element der Kollektion true ist.

forAll( expression ) True, wenn expression für alle Elemente true ist.

304

Konstrukte der OCL

• Operation „equals“

• equals ergibt true, wenn

– zwei Sets dieselben Elemente enthaltenSet {1,2,5,88} = Set {2,88,1,5}

– bei zwei Bags auch die Anzahl des jeweiligen Elements gleich ist Bag {’Willi’,’Erna’,’Horst’,’Willi’} = Bag {’Erna’,’Willi’,’Horst’,’Willi’}

– bei Sequenzen zudem die Reihenfolge gleich ist – Sequence {1..(6+4)} = Sequence {1,2,3,4,5,6,7,8,9,10}

305

Konstrukte der OCL

• Operation „union“

• Kombination von zwei Kollektionen– Set mit Bag

Set {1,2,5,88}-> union( Bag {3,7,27} ) = Bag {1,2,5,88,3,7,27}

– eine Sequence kann nur mit einer anderen Sequence kombiniert werden

306

Konstrukte der OCL

• Operation „including“

• hinzufügen von Elementen– bei Sets nur, wenn das Element noch nicht

vorhanden istSet{1,2,5,88}-> including({27,5})= Set{1,2,5,88,27}

– bei einer Sequence wird am Ende eingefügtSequence{1,2,5,88}-> including({27})= Sequence{1,2,5,88,27}

307

Konstrukte der OCL

• Operation „excluding“

• entfernt ein Element– bei einem Set wird nur ein Element entfernt

Set{1,2,5,88}-> excluding({5}) = Set{1,2,88}

– bei Bag und Sequence bei jedem Auftreten entfernenSequence{1,2,5,2,88}-> excluding({2})= Sequence{1,5,88}

308

Konstrukte der OCL

• Operation „intersection“

• erzeugt neue Kollektion mit allen Elementen, die in zwei Kollektionen enthalten sind

• alle Kombinationen möglich, außer in Verbindung mit einer Sequence

Set {1,2,5,88} -> • intersection( Bag {5,5,1} ) = Set {1,5}

Bag {1,2,5,1,88} -> intersection( Bag {1,27,5,1} ) = Bag {1,5,1}

309

Konstrukte der OCL

• Spezielle Operationen für Set

• minus– Set{1,4,7,10} – Set{4,7} = Set{1,10}

• symmetricDifference– neues Set mit Elemente, die nicht in beiden Sets

enthalten sindSet{1,4,7,10}.symmetricDifference(Set{4,5,7})

– = Set{1,5,10} 310

Konstrukte der OCL• Spezielle Operationen

• für Sequence

• „first“ bzw. „last“

– Ausgabe des ersten bzw. letzten ElementsSequence{1,4,7,10} -> last = 10Sequence{1,4,7,10} -> first = 1

• „at()“

– Element an der angegebenen PositionSequence{1,4,7,10} -> at(3) = 7

– „append()“ bzw. „prepend()“

– Einfügen an letzter bzw. erster PositionSequence{1,4,7,10} -> prepend(15) = Sequence{15,1,4,7,10}

311

Konstrukte der OCL

• Operationen • für Elemente einer Collection

• „Select“• Parameter ist ein boolscher Ausdruck• Ergebnis ist eine neue Kollektion

– Unterstruktur der Ausgangskollektion

• Syntax:collection->select( element : Type | <expression> )collection->select( element | <expression> )collection->select( <expression> )

312

Konstrukte der OCL


• „reject“• ergibt neue Kollektion mit Elementen, für die der

boolsche Ausdruck false ergibt

• „collect“• Ergebniskollektion muss nicht eine Unterstruktur der

Ausgangskollektion sein• durch Anwendung auf ein Set kann ein Bag entstehen

313

Konstrukte der OCL


• „exists“• prüft die Elemente auf Existenz des Parameters• Ergebnis ist vom Typ Boolean

• „forAll“• spezifiziert eine Bedingung, die für alle Elemente zutreffen

muß• Ergebnis ist vom Typ Boolean

314

Konstrukte der OCL

• Operationen

• für Elemente einer Collection

• „iterate“

• vorherige Operationen sind Spezialfälle von iterate

• Syntax:

collection->

• iterate(element : Type1;result : Type2 = <expression>|

• <expression-with-element-and-result>)315

Quelle: Schürr 2007316

Nutzerdefinierte Typen

• Durch den Benutzer definierte OCL-Typen

• neue Typen haben die gleiche Gültigkeit wie vordefinierte Typen

• Klassentypen

• Aufzählungstypen

317


• jede Klasse im Klassendiagramm ist ein Klassentyp (Modelltyp) im OCL-Ausdruck

• Name aus dem UML-Modell wird übernommen

• Generalisierung zwischen den Klassen führt zu Supertypen

318


• Attribute

• Operationen und Methoden

• Klassenattribute

• Klassenoperationen

• Assoziationsenden („Navigationsausdrücke“)

319


• Gültige Arten für Nutzerdefinition sind:

• Typen

• Klassen

• Interfaces

• Assoziationen

• Akteure

• Use Cases

• Datentypen320


• Klassenattribute im UML-Modell sind

• gültige Attribute im OCL.

• Beispiel:

• Customer

• self.name321


• Seiteneffektfrei

• Nur Operationen, die den Zustand aller

• anderen Objekte nicht verändern.

• Query Operations

• Operationen, die nur einen Rückgabewert

• liefern, aber keine Veränderungen

• vornehmen.

• Beispiel:

• Customer

• self.age() >= 0322


• abgeleitet aus den Assoziationen• Name der Navigationen:

– Rollenname am anderen Ende einer Assoziation oder

– Name des Typen am Ende der Assoziation in Kleinbuchstaben

• Ergebnis:– Modelltyp bei einem Wert oder– Kollektion von Modelltypen bei mehreren Werten

323


• im UML ist Mehrfachvererbung möglich

• Problem:

CassetteBookself.volume < 10

• nicht eindeutig, ob volume von Book oder Cassette gemeint ist

Cassette

volume : Integer

Book

volume : Integer

CassetteBook

324


• Lösung:

• Das im OCL vorhandene pathname

• Konstrukt.

• Beispiel:

• CassetteBook

• self.Cassette::volume < 10325


• Aufzählungen häufiger Attributtyp in der UML• Darstellung im UML-Modell:

enum{wert1, wert2, wert3}• wird ein Wert in einem OCL-Ausdruck benutzt, muss

das `#`-Symbol vorangestellt werden

• Customergender = #male implies title = ´Mr.´

Customer

gender : enum{male, female}name : Stringtitle : StringdateOfBirth : Date

326

Typkonformität

• OCL ist eine getypte Sprache

• Basistypen sind in einer Typenhierarchie organisiert

• innerhalb eines OCL-Ausdrucks müssen alle Typen konform sein

• Regeln zur Gewährleistung der Konformität:– jeder Typ ist zu sich selbst konform– jeder Typ ist konform zu seinem Supertyp– Typenkonformität ist transitiv

327

Typkonformität

Type Konform zu/Supertyp

SetSequenceBagInteger

CollectionCollectionCollectionReal

328

Übung

• Ein Objekt der Klasse Teilnahme muss

• immer gültige Verweise auf die

• assoziierten Objekte Spiel und Spieler

• besitzen.

• context Teilnahme t inv:

• (t.Spieler != null) && (t.Spiel != null)

329

Übung

• Nimmt ein Spieler an einem Spiel teil, so

• kann er während der nächsten 105

• Minuten nicht an einem anderen Spiel

• teilnehmen.

• context Spieler spieler inv:

• forall Spiel s1,s2 in spieler.teilnahme.spiel:

• (s1 != s2) implies

• ((s1.getDatum() > s2.getDatum() + 105 * 60) ||

• (s2.getDatum() > s1.getDatum() + 105 * 60))

330

Übung

• Sobald 11 Spieler für ein Spiel nominiert

• wurden ist die Mannschaft komplett.

• context Spiel::mannschaftKomplett():boolean

• pre: true

• post: result == (teilnehmer.size() >= 11)

331

Links zur UML

http://www-ivs.cs.uni-magdeburg.de/~dumke/UML/inhalt.htm

http://www.cetus-links.org/oo_uml.html http://www.uml.org http://www.iwr.uni-heidelberg.de/groups/co

mopt/lehre/uml/ http://www.jeckle.de/unified.htm http://www.sigs-datacom.de/sd/

publications//os/1998/02/OBJEKTspektrum_UM_kompakt.htm

332



http://www.cetus-links.org/oo_uml.html

http://www.uml.org/

http://www.iwr.uni-heidelberg.de/groups/comopt/lehre/uml/

http://www.iwr.uni-heidelberg.de/groups/comopt/lehre/uml/

http://www.jeckle.de/unified.htm

Qualitätssicherung

• Unter den Sammelbegriff Qualitätssicherung im SE fallen diverse Verfahren, die parallel zu den Vorgehensmodellen für eine ständige Überprüfung und Messung (mit quantitativen Methoden) der Prozesse und Ergebnisse sorgen. Diese Verfahren wurden zum Teil aus dem Bereich der Fertigung übertragen (ISO9000, TQM).

333

Qualitätssicherung

• Ein wesentlicher Aspekt dieser QS-Verfahren ist die dem Kunden eröffnete Kontrollmöglichkeit und die Einbeziehung externer Organisationen (z.B. zur Zertifizierung).

334

Verfahren der Qualitätssicherung

• ISO 9000

• TQM

• CMM / CMMI

• Bootstrap

• Spice

335

Exkurs: XP als Antithese zum SE

336

Einleitung“Angeklagt: Agile Prozesse”

Angeklagt sind die agilen Prozesse, vertreten durch die Verteidiger

von Extreme Programming (XP), Crystal Methodenfamilie, Adaptive

Software Development, Scrum und die Agile Alliance.

Die Anklage lautet auf

- Verrat am Software Engineering,

- Versuch des Umsturzes durch Wiedereinführung wilden Hackens

- sowie auf Totschlag tausender Arbeitsplätze

- und Milliarden Umsätzen in der Software-Industrie.

Als Schöffen entscheidet das Auditorium über das Urteil.

Für sachdienliche Hinweise...

Quelle: Delegate Information zur OOP 2002337

AnsätzeDas Revolutionäre an XP

Extreme Programming stellt bisherige Paradigmen des Software Engineering auf den Kopf:

- Entwickler spezialisieren sich nicht zu Analysten, Programmierern,

Testern oder Integratoren - jeder ist für alles zuständig.

Deshalb wurden Programmierrichtlinien an XP angepasst.

- Das Projekt wird nicht durchgeplant. Eine schnelle Analyse wird

im Laufe des Projekts weiter verfeinert und verändert.

- Die Projektphasen bisheriger SE-Modelle werden parallelisiert:

Es wird laufend das Design angepasst, getestet, integriert...

- Es gibt keine Dokumentation im herkömmlichen Sinn.

Dokumentiert wird durch Tests und programmierten Code.

- XP versucht, den Problemem und Risiken des herkömmlichen

Software Engineering aktiv entgegenzuwirken. 338

PlanungProjektablauf im Vergleich

Design

Implementierung

Test

Integration

Plan

nin

g G

ame

Re

lease

Story

Ta

sk

Zeit

VorstudieAnalyse

DesignKonstruktion

TestEinführung

Extre

me

Pro

gram

ming

Wa

sserfall-

mo

de

ll

339

PlanungPlanning Game

Im Planning Game stecken Kunde und Entwickler die Eckpunkte des

Projekts ab.

Kunde Story Cards Gliederung der Funktionalität

Priorisierung nach Wert, Risiko,

Aufwand, Umfang der Releases

Entwickler Architektur Abschätzung der Möglichkeiten

für Architektur

Releaseplanung Zeitplanung für 1. Release

Aufteilung in Iterationen340

PlanungIterationsplanung

In der Iterationsplanung verteilt werden Stories an die Entwickler verteilt

und geplant.

Entwickler Task Cards “Feinplanung der Stories”

Taskverteilung

Aufwandsschätzung

evtl. Taskumverteilung

Kunde bekommt Feedback von Entwicklern.

341

ProjektumfeldArbeitsplätze

Für die Umsetzung von Extreme Programming sind speziell angepasste

Arbeitspläte nötig.

Zentrale Forderung:

Kommunikation soll gefördert werden, ohne die Privatsphäre zu verletzen.

Großraumbüro mit “private cubbies”.

Entwicklungsrechner im Zentrum des Raums.

“Communal Corner” mit Kaffeemaschine, Couch, Snacks.

leise Telefone, gedämpftes Licht.

Team soll von anderen Teams getrennt sein.342

Projektumfeld 40-Stundenwoche

Extreme Programming lebt von der Kreativität und Motivation des Teams.

Um Kreativität und Motivation langfristig zu erhalten

- sollte die Wochenarbeitszeit um 40 Stunden liegen,

- die 40-Stundenwoche nicht an zwei aufeinanderfolgenden

Wochen signifikant überschritten werden.

Wird mehr gearbeitet als 40 Stunden pro Woche,

- lassen Kreativität, Motivation, Konzentration und

Leistungsfähigkeit nach.

- gibt es größere Probleme im Projekt, die sich durch Überstunden

nicht lösen lassen.343

ProjektumfeldOn-Site Customer

Um ein Projekt im Sinne des Kunden zu erarbeiten,

- muss ein Mitarbeiter des Kunden ständig vor Ort sein,

- muss der abgestellte Mitarbeiter die nötigten Kenntnisse haben,

um auf fachspezifische Fragen der Programmierer einzugehen.

Ein Mitarbeiter des Kunden vor Ort

- verkürzt die Dauer des Projekts,

- verhindert, dass am Kunden vorbei entwickelt wird,

- kann Functional Tests schreiben (lassen).

344

UmsetzungSimple Design

Das Design sollte so gehalten werden, dass

- es minimal bleibt: so wenige Klassen und Methoden wie möglich

und so viele wie nötig. Doppelte Logik ist unerwünscht.

- es an veränderte Bedürfnisse angepasst werden kann,

- jeder Gedanke des Programmiers deutlich wird,

- alle Tests durchlaufen.

Die Software wird nur bei Bedarf erweitert.

Es wird nicht “vorsorglich” Funkionalität eingebaut.

exponentielles Ansteigen der Cost-Of-Change-Kurve wird

vermieden.345

UmsetzungTesting I

Design-, Architektur- und Codeänderungen führen nur dann zum Erfolg,

wenn sie durch Tests abgesichert sind.

Deshalb stehen Tests im Mittelpunkt von Extreme Programming.

Zunächst gibt es 2 grundlegende Testtypen:

- “functional tests” des Kunden

- story-by-story

- Erfüllungsgrad erst zu Ende 100%

- “operational tests” der Entwickler

- method-by-method

- Erfüllungsgrad von Anfang an 100%

Weitere Testtypen: Vergleichstest mit altem Programm, Lasttests 346

UmsetzungTesting II

Die Entwicklung eines Tests

- Der Test muß vor dem eigentlichen Coden programmiert werden.

- Ein Test darf einen anderen Tests nicht beeinflussen.

Der Ablauf von Tests

- Die Tests müssen automatisiert werden können.

- Alle Tests laufen zusammen ab.

- Tests werden nach jeder Codeänderung gestartet.

Durch Tests

- werden Funktionalität und Qualität sichergestellt.

- wird das Selbstbewusstsein bei Entwicklern und Kunden gesteigert.

347

UmsetzungPair Programming

An der Programmierung von Code sind 2 Programmierer beteiligt:

- Ein Programmierer tippt den Code ein.

- Der Partner denkt strategisch:

- Führt die Implementierung zum Ziel?

- Gibt es noch Testfälle, die abzuprüfen sind?

- Kann das Problem vereinfacht werden?

Pair Programming ist

- dynamisch: die Paare wechseln ständig,

- nicht für jeden Typ Programmierer geeignet.

Wissen wird gestreut und macht Team leistungsfähiger.

Die Wahrscheinlichkeit, sich festzufahren, fällt. 348

Dem Problem vom unwartbaren Code eines Programmiergurus tritt

Extreme Programming mit 3 Prinzipien entgegen:

Coding Standards Es gibt für alle Programmierer

einheitliche Programmierrichtlinien,

Collective Ownership Jeder Programmierer jeden Teil

des Codes ändern,

Refactoring Der Code wird vereinfacht, wenn er

vereinfacht werden kann.

Einfacher, verständlicher, stabiler und wartbarer Code.

Umsetzung

349

UmsetzungContinous Integration

Um kurze Releasezyklen zu ermöglichen,

- sollte mindestens einmal täglich integriert werden,

- fließen Änderungen zentral an einem Rechner zusammen

Integration inkompatiblen Codes wird vermieden.

Continous Integration erfordert

- kleine Objekte und Methoden,

- Refactoring und Simple Design,

- das erfolgreiche Durchlaufen aller Tests.

Minimales Risiko, da Bug in letzten Stunden entstand.

Kein Verrennen in Probleme.350

BewertungWann ist XP nicht sinnvoll?

Für XP gibt es K.O.-Kriterien, die einen Einsatz ausschließen.

Extreme Programming wird zur Farce, wenn...

... der Kunde - nicht bereit ist, XP-Prinzipien anzuwenden und zuzulassen.

... das Team - dauerhaft unter Druck steht und Überstunden machen muß,

- XP-untaugliche Arbeitsplätze hat,

- ein Mitglied hat, das sich gegen XP-Richtlinien sträubt.

... das Projekt - so überschaubar ist,daß kein Vorgehensmodell benötigt wird.

- so groß ist, daß

- mehr als 10 Entwickler benötigt werden,

- mehr als ein Integrationsrechner benötigt wird,

- der Test- oder Integrationszyklus Stunden benötigt.351

BewertungWann ist XP sinnvoll?

Extreme Programming ist eine Überlegung wert, wenn...

... keiner der Punkte auf der vorherigen Folie zutrifft.

352

Quellen zu XP

Beck, Kent: extreme Programming explained: embrace change

Upper Saddle River, NJ, Addison-Wesley, 2000

- Grundlagen, Prinzipien und Funktionsweise von XP

- keine theoretischen Fallstudien und tiefgehende Details,

aber Beispiele aus der Praxis und umfassender Überblick

- auch in deutsch erhältlich unter dem Titel

“Extreme Programming - Das Manifest” (Addison-Wesley)

www.extremeprogramming.org

- weitergehende Informationen

- Anwendungsbeispiele aus der Praxis 353

Folien zum Software Engineering Aus urheberrechtlichen Gründen (Verletzung von Rechten Dritter)...

Documents

Transcript of Folien zum Software Engineering Aus urheberrechtlichen Gründen (Verletzung von Rechten Dritter)...