Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Folien zum Software Engineering

Ähnliche Präsentationen


Präsentation zum Thema: "Folien zum Software Engineering"—  Präsentation transkript:

1 Folien zum Software Engineering
Mein Dank gilt allen Studierenden, die insbesondere durch aufwendige grafische Darstellungen und Diagrammbeispiele zu dieser Foliensammlung beigetragen haben. Aus urheberrechtlichen Gründen (Verletzung von Rechten Dritter) dürfen Sie diese Foliensammlung nicht öffentlich zur Verfügung stellen (www oder ftp)!

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

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

4 Vorlesung und Übungen

5 Literatur zum Thema Software-Engineering
(Kahlbrandt) B. Kahlbrandt: Software-Engineering: Objektorientierte Software-Entwicklung mit der Unified Modeling Language, Springer Verlag, 2. Aufl. 2001, ISBN: (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

6 Literatur zum Thema Software-Engineering (im WWW)
(Schürr1) (Schürr2) (Gruhn) (Prechelt) (SE-VV)

7 Inhalt (1) Einführung Was bietet die Informatik? Vorgehensmodelle
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

8 Inhalt (2) Übergang zur Programmierung / Codegenerierung
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

9 Inhalt (3) Testen Qualitätssicherung Weitere Vorgehensmodelle
Überblick Fehler Statische Verfahren Dynamische Verfahren Qualitätssicherung ISO 9000 TQM CMM Weitere Vorgehensmodelle XP (Extreme Programming)

10 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

11 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

12 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 werden

13 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“

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

15 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.“

16 Prinzipien des SE Abstraktion / Modellierung
Schrittweise Verfeinerung / Hierarchisierung Modularisierung Vgl. Gruhn , F. 46 ff.

17 Qualitätsmerkmale von Software
korrekt robust zuverlässig effizient es gibt noch viele offene Wünsche: wartbar, wiederverwendbar, portierbar, kompatibel, benutzerfreundlich, interoperabel

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

19 Softwarekrise Kosten Zeit Quelle: Herde vhb

20 Aus: Schürr1

21 Aus: Schürr1

22 Abbruchrate Aus: Gruhn, F. 16

23 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

24 Kostenfaktoren (aus Pieper)
Änderungen in den Benutzeranforderungen Änderungen in Datenformaten Notfallrettungsaktionen Routinefehlerbehebung Hardware-Änderungen Dokumentation Verbesserungen Sonstiges

25 Wie groß sind bekannte Programme?
SAP R/3 (1994): Zeilen Sourcecode Funktionsaufrufe Funktionen Menüleisten Reports · Space Shuttle Instruktionen · EWSD (elektronisches Wählsystem ISDN) ? Instruktionen

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

27 Was bietet die Informatik?
Prinzipien des SE Prozessmodelle / Vorgehensmodelle Modellierungstechniken Werkzeuge (Programme zur Unterstützung der Softwareentwicklung)

28 Was beinhalten Prozessmodelle?
Vorgehensmodell Ergebnisse Techniken Tool Rollen Wann Was Wie Womit Wer

29 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

30 Typisches Vorgehensmodell
Vorstudie / Planung Analyse Design Konstruktion Test Einführung

31 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

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

33 Vorgehensmodelle: Empirie
„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.“ (Quelle:http://www.dlr.de/IT/IV/Studien/evasoft_abschlussbericht.pdf)

34 Vorgehensmodelle: Empirie
„Allerdings ist zu beobachten, dass die Einhaltung von Vorgehensmodellen überwiegend in das Ermessen einzelner Entwicklungsabteilungen gestellt wird; es gibt hier noch wenig Verbindlichkeit.“ (Quelle:http://www.dlr.de/IT/IV/Studien/evasoft_abschlussbericht.pdf)

35 Vorgehensmodelle: Empirie
„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.“ (Quelle:http://www.dlr.de/IT/IV/Studien/evasoft_abschlussbericht.pdf)

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

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

38 Projekte Ergebnis / Projektziel
einmalig und in überschaubarem Zeitraum erreichbar temporäre, arbeitsteilige Organisation neben der bestehenden Aufbauorganisation / Projektgruppe Betrachtung aus wirtschaftlicher Sicht / Projektcontrolling

39 Projektmanagement / Planung
Aktivitäten Ressourcen (Kapazitäten und Mitarbeiter) Termine Kosten

40

41 Projektmanagement / Steuerung
Kontrolle von Leistungen, Kosten und Terminen Koordination Information der Projektmitglieder und Berichterstattung an den Lenkungsausschuss

42 Projektmanagement / Kontrolle
Einhaltung des Projektplans Abweichungsanalyse Projektreviews (eventuell durch externe, unabhängige Spezialistenteams)

43 Der Projektmanager Gutes Projektklima sichern
Kontakt zu sonstigen vom Projekt berührten Stellen pflegen Ressourcen beschaffen Vertretung von Teammitgliedern

44 Das Projektteam IT-Spezialisten
Vertreter aus dem Anwendungsbereich mit genügend Zeit und Lernbereitschaft Kommunikative Fähigkeiten sind gefragt 5-7 Personen

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

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

47 Phasen von Rational Unified Process

48 Rollenverteilung Budget-Controller Qualitäts-Manager Tester
Überprüft Arbeitsergebnisse Überprüft Arbeitsergebnisse C Liefert Programm Tester Programmierer B Liefert Spez. Budget-Controller A steht zu B in der Beziehung C Designer Berichtet an Überprüft Kostenberichte Macht Vorgaben Vors. GF Marketier Vertriebler Projektleiter Berichtet an Kündigt Produkt an Versendet Werbematerial Fordert Nachbesserung Gruhn, F.26 Kunde

49 CASE CASE Einführung Rational Rose Andere Tools

50 CASE Computer Aided Software Engineering
Editoren zur Erstellung von Diagrammen Gemeinsames Repository / Enzyklopädie Automatische Generierung von Programmcode und Datenbankspezifikation

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

52 CASE-Tool: Beispiele

53 CASE-Tool: Beispiele

54 Funktionsstruktur

55

56

57

58 Datenstruktur

59

60

61 Relationenmodell

62 CASE-Tool Links http://osiris.sunderland.ac.uk/sst/case2/tools.html
(freies UML-Tool Argo) (freies UML-Tool Poseidon)

63 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

64 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

65 „Bestellsystem für Pizzaservice“
Beispiel (2) Lastenheft „Bestellsystem für Pizzaservice“ Version 1.0 Datum: 1. Zielbestimmung Der Pizzaservice „Rapido“ soll in die Lage versetzt werden, Kundendaten und telefonische Bestellungen mit einem EDV System zu verarbeiten.

66 Beispiel (3) 2. Produkteinsatz
Das Produkt dient zur Verwaltung von Kunden und Bestellungen. Zielgruppe sind die Mitarbeiter des Pizzaservice.

67 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 Rechnung

68 Beispiel (5) 4. Produktdaten (LD = Lastenheftdaten)
/LD10/ Relevante Kundendaten sind zu speichern /LD20/ Relevante Produktdaten sind zu speichern /LD30/ Relevante Bestelldaten sind zu speichern

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

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

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

72 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

73 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 Daten

74 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

75 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

76 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 werden

77 vgl. H. Balzert: Lehrbuch der Software-Technik, 2000
Funktion Points Produktanforderungen 1 Eingabedaten Abfragen Ausgabedaten Datenbestände Referenzdaten 2 2 2 2 2 einfach mittel komplex 3 Anzahl Gewichtung Eingabedaten 3 mittel x 4 12 Abfragen 1 einfach x 3 Ausgabedaten Datenbestände Referenzdaten 4 Einflussfaktoren 5 290 x 0,955 vgl. H. Balzert: Lehrbuch der Software-Technik, 2000

78 Eingabedaten

79 Ausgabedaten

80 Alternative Bewertung für die Komponente Ausgabedaten:

81 Datenbestände

82 Abfragen

83 Referenzdaten

84 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

85 Festlegen der Einflussfaktoren der gesamten Anwendung
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)

86 Festlegen der Einflussfaktoren der gesamten Anwendung
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

87 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;

88 Ableitung nach Erfahrungstabelle bzw. -kurve

89 vgl. H. Balzert: Lehrbuch der Software-Technik, 2000
Funktion Points 290 x 0,955 = 276,95 5 6 7 Aufwand Aktualisierung vgl. H. Balzert: Lehrbuch der Software-Technik, 2000

90 LOC pro Point C C HTML Java 29 Pascal 91 SQL 13 Visual Basic 5 29

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

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

93 Anwenden der Function Point Methode (1)
1. Schritt Einordnung der Produktanforderungen in Kategorien

94 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

95 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

96 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

97 Anwenden der Function Point Methode (5)
Abfragen: einfacher, elementarer Prozess einfache Ausgabe von Daten keine weitere Verarbeitung hier: /LF30/: Anzeige der Kundendaten

98 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

99 Anwenden der Function Point Methode (7)
2. Schritt: Klassifizierung der Funktionen und Daten Eingabedaten:

100 Anwenden der Function Point Methode (8)
Ausgabedaten und Abfragen

101 Anwenden der Function Point Methode (9)
Datenbestände und Referenzdaten

102 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

103 Anwenden der Function Point Methode (11)
/LF20/: Produktdaten ein Datentyp vier Datenfelder einfach /LF40/: Bestelldaten drei Datentypen zehn Datenfelder komplex

104 Anwenden der Function Point Methode (12)
Abfragen: /LF30/: Abfrage der Kundendaten ein Datentyp sechs Datenfelder einfach

105 Anwenden der Function Point Methode (13)
Ausgabedaten: /LF50/: Ausgabe von Backauftrag, Lieferauftrag und Rechnung drei Datentypen 20 Datenfelder komplex

106 Anwenden der Function Point Methode (14)
Datenbestände: /LD10/, /LD20/, /LD30/ jeweils ein Datentyp weniger als je 20 Datenfelder alle einfach

107 Anwenden der Function Point Methode (14)
3. Schritt Berechnung der unbewerteten Function Points

108 Anwenden der Function Point Methode (15)
4. Schritt: Bestimmung von Einflussfaktoren Auf- oder Abwertung der unbewerteten Function Points um  30 Prozent

109 Anwenden der Function Point Methode (16)
Einflussfaktoren im einzelnen: Verflechtung mit anderen Anwendungssystemen dezentrale Daten, dezentrale Verarbeitung Transaktionsrate Verarbeitungslogik Wiederverwendbarkeit Datenbestandskonvertierungen Anpassbarkeit

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

111 Anwenden der Function Point Methode (18)
Transaktionsrate (0-5) Zusatzannahme: Einzelplatzsystem häufige Bestellannahme hier mittlere Transaktionsrate: 3

112 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üfung

113 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

114 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

115 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

116 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

117 Anwenden der Function Point Methode (21)
Die bewerteten Funktion Points siehe Blatt Einflussbewertung E3 ermitteln Berechnung der bewerteten Function Points

118 Anwenden der Function Point Methode (22)
6. Schritt Umrechnung in Mitarbeitermonate (MM) firmenspezifische Tabelle oder Graph Function Points vs. MM empirische Daten notwendig ggf. Tabelle / Graph aus ähnlichem Umfeld

119 IBM - Tabelle

120 Anwenden der Function Point Methode (23)
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

121 Modellierungstechniken
„Klassische“ Techniken ER-Diagramme Strukturierte Analyse (SA)/ Datenflußdiagramme (DFD) Nassi Shneidermann Struktogramme Pseudocode /Aktionsdiagramme Objektorientierte Techniken UML (Beispiele)

122 Einordnung diverser Techniken

123 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“

124 Kardinalität der Beziehungen
1:1 1:N M:N

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

126 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

127 Beziehungen Optional oder obligatorisch
Parallele Beziehungen (z. B. Person – Versicherungspolice) Reflexive Beziehungen (z. B. zur Darstellung der Mitarbeiterhierarchie)

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

129 Obligatorische Beziehungen
Rechnung Rechnungsposition Eine Rechnung ohne Rechnungsposition soll nicht vorkommen dürfen.

130 Reflexive Beziehungen
Ist verheiratet mit Mitarbeiter Ist Vorgesetzter von

131 Parallele Beziehungen
Ist Versicherungsnehmer Person Versicherungspolice Ist Versicherte Person

132 Strukturierte Analyse
Meistbenutzte Technik in der Praxis Einfach zu erlernen

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

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

135 Prozesse Prozesse verarbeiten Daten Buch vormerken 1.2

136 Datenspeicher Vormerkungen

137 Endknoten (Terminatoren)
Endknoten sind Akteure oder Datenspeicher außerhalb des betrachteten Systems, die Daten senden oder empfangen. Kunde

138 Datenflüsse Vormerkungen Datenflüsse transportieren Daten
Sie können beschriftet werden Vormerkungen Buch vormerken 1.2 Akzeptierte Vormerkung

139 Datenspeicher Vormerkungen Ausleihen
Direkte Verbindungen zwischen Datenspeichern sind verboten Vormerkungen Ausleihen

140 Hierarchiekonzept der „Strukturierten Analyse“
Kontext-Diagramm Ebene 0: Datenfluß-Diagramm 1. 2. 0. 3. Prozeßspezifikation ____________________________________________

141 Struktogramm (Auswahl)
Ausdruck wahr falsch Ja-Anweisung Nein-Anweisung (bei einseitiger Auswahl leer) Anweisung(en) Quelle: Herde vhb

142 Pseudocode while (Ausdruck) { Wiederholungsanweisung(en);
} while (Ausdruck); Anweisung(en); Quelle: Herde vhb

143 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

144 Diagramme der UML Strukturdiagramme Verhaltensdiagramme Aktivitätsdiagramm Use-Case diagramm Klassen- diagramm Objekt- diagramm Komponenten- diagramm Verteilungs- diagramm Zustands- diagramm Interaktionsdiagramme Kompositions- Strukturd. Paket- Diagramm Sequenz- diagramm Interaktions- übersichtsd. Kommunikations- diagramm Timing- diagramm

145 Quelle: Casetool MID Innovator

146 Use-Case Diagramm

147 Sequenzdiagramm

148 Klassendiagramm

149

150 Zustandübergangsdiagramm

151 Stereotypen von Klassen (Rose-Tutorial)

152 Zustandübergangsdiagramm
© H. Balzert 2001

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

154 Eigenschaften von Aktivitätsdiagrammen
Aktivitätsdiagramme = Kontrollflussdiagramme + Zustandsdiagramme Kontrollflussdiagramm: Zustandsdiagramm: Aktivitätsdiagramm

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

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

157 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

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

159 Elemente Fallunterscheidungen: Es darf keine Schnittmengen
zwischen den Bedingungen geben (eine muss erfüllt sein):

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

161 Einfaches Beispiel Anfangszustand Aktivität Auftrag erhalten Bedingung
Aufspaltung Auftrag fertig stellen Entscheidung Rechnung senden [Eilauftrag] [else] Zahlung erhalten Über Nacht Auslieferung Normale Auslieferung Synchronisation Auftrag abschließen Zusammen- führung Endzustand

162 Elemente Schwimmbahnen (“swimlanes”) verdeutlichen die Verantwortlichkeiten: Organisationseinheiten (konzeptionell) Klassen (spezifizierendes, konzeptionelles Modell) Abteilung 1 Abteilung 2 Abteilung 3

163 UML - Aktivitätsdiagramm (Notation)
Synchronisation der Kontrolle (AND) mit Synchronisationsbedingung (Join) Aufsplitten der Kontrolle (Zulassen von Parallelität, Fork) Aktivität Aktivität Kontrollfluß Aktivität2 wird nach Abschluß von Aktivität1 gestartet. Verzweigung(-saktivität) (kann auch durch normale Aktivität dargestellt werden) Kontrollfluß, der unter der angegebenen Bedingung gewählt wird. [Bedingung] Aktivität1 Aktivität2 [Bedingung]

164 UML - Aktivitätsdiagramm (Notation)
Aktivität wird durchgeführt, wenn über einen der eingehenden Kontrollflüsse die Kontrolle ankommt (OR) Start des Ablaufs (mit Aktivität) Ende des Ablaufs (optional) Aktivität

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

166 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

167 Lösung (Adresse suchen)

168 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

169 Lösung (neue Adresse aufnehmen)

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

171 Lösung der Übungsaufgabe

172 Aktivitätsdiagramm © H. Balzert 2001

173 Quelle: http://www. informatik. fh-wiesbaden
Quelle: letzte Seite

174 OMG Spec. 1.4

175 OMG Spec. 1.4

176 Checkliste für Zustandsfindung
Identifikation relevanter Ereignisse Zeitlich gruppieren

177 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

178 Kommunikations-/Kollaborationsdiagramm
Statische Sicht auf die beteiligten Objekte wie im Klassendiagramm Verschiedene Notationselemente zur Charakterisierung der Nachrichten

179 Aus:

180

181

182 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 an einen Freund und arbeiten danach weiter.

183 Arten von Nachrichten 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.

184 Arten von Nachrichten 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.

185 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

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

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

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

189 Ein Beispiel für die Anwendung eines solchen Multiobjektsymbols ist z
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.

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

191 Elemente eines Kollaborationsdiagramms
Verbindungen zwischen Objekten

192 Elemente eines Kollaborationsdiagramms
Nachrichten: Diese werden auf den kleinen Pfeilen über oder unter den Verbindungen notiert. Allgemeiner Nachrichtenaufbau: [Vorgängerbedingung]Nummerierung:[Antwort:=]Nachrichtenname(Argumentenliste)

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

194 Beispiel Aus: Kahlbrandt, Software Engineering

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

196 Nach:http://www. objectmentor

197

198

199 Sequenzdiagramm

200

201

202 Use-Case Beschreibung
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 feststellen 2. Buchungsperiode bestimmen 3. Buchungen erzeugen (1-n) 4. Journal bedienen 5. Buchungskontrolle Aktor: System Variantenbeschreibung: - keine -

203

204 Zustandsdiagramme

205 Systembeschreibende Diagramme
Paketdiagramm Komponentendiagramm Verteilungsdiagramm

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

207 Notationselemente eines Paketdiagramms
Ein Paket fasst Modellelemente sinnvoll zusammen und definiert einen Namensraum für die enthaltenen Elemente. {import Packet B :: Element A} <<import>> Paket-Import Importiertes Paket Importierendes Paket Paket A Paket B + Element A Alternative Darstellung des Paket-Imports:

208 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 Paket Importierendes Paket Paket A Paket B + Element A Alternative Darstellung des Paket-Imports:

209 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

210 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-Acces Paket A Paket B + Element A {access Packet B :: Element A} Alternative Darstellung des Paket-Acceses:

211 - automatennummer: int - umsatz: float + karte einziehen()
Administrator - name: String - geburtsdatum: Date <<import >> <<access>> Geldautomatensystem Geldautomat - automatennummer: int - umsatz: float + karte einziehen() + eingabGeheimzahl(int pin) + transaktionstarten() + seriennummereinlesen() + karteausgeben() + geldausgeben() Bankkundenverwaltung Privatkunde - vorname: String - nachname: String Geschäftskunde - firmenname: String Kontoverwaltung Umsatz - datum: Date - nummer: int - betrag: float - umsatzweck: String Datenverwaltung Datenbank Datenpflege Bank - bankleitzahl: int - ort: String Girokonto - sollzins: float - dispokredit: float + auszahlen (betrag: float) + zinsgutschreiben() + sollzinsabbuchen() Sparkonto - höchstbetrag: float

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

213 Stereotyp der Komponente
Komponentensymbol Komponente <<component>>

214 Beispiel

215 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

216 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 <<component>> Teilnehmerverwaltung

217 Komponentensymbole in Rational Rose
Ausführbare: Library: Table: File: Dokument:

218 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

219 Beispiele für Komponenten
Exe-Dateien Dll Programmbibliotheken Java-Dateien Datenbanktabellen ...

220 Weitere Stereotypen <<script>> (Script-Datei)
<<document>> (Dokument) <<executable>> (ausführbare Datei) <<file>> (nicht näher spezifizierte Datei) <<library>> (Bibliotheksdatei) <<source>> (Quelltext)

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

222 Schnittstellen und Ports
benötige Schnittstelle realisierte Klasse B Klasse A

223 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 Komponente B

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

225 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 <<component>> Teilnehmerverwaltung <<artifact>> teilnehmer.jar

226 <<manifest>>
<<component>> Konto-DBMS Einzahlung Auszahlung Speichermedium Kontoverwaltung Geldautomaten-GUI <<artifact>> Oracle 10g

227 komplexer Port ExternesDisplay zeigt Zeit Display Wecker Uhrzeit StandardFunksignal

228 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 A Ersetzte Komponente Substituierende Komponente <<substitute>> <<component>> Komponente A Komponente B

229 Kombination Schnittstellen können mit Hilfe von Ports organisiert werden WahlfreierZugriff Speichermedium SortierterZugriff <<component>> Teilnehmerverwaltung

230 Verteilungsdiagramm Spezifizieren der physischen Hard- und Softwareumgebung Wird in der Entwurf/Design-Phase erstellt Auf seiner Basis Entscheidung über: Hardware- und Softwarekomponenten Komponentenverteilung (Software) Kommunikationsbeziehungen zwischen Knoten

231

232 Knoten Stereotyp des Knoten <<device>> Server
Name des Knotens Knoten

233 Attribute <<application server>> Applikationsserver
+ prozessor: GHz = 3.2 + RAM GByte = 16 + Festplatte: GByte = 600 Attributname Attributtyp Vorgabewert

234 Operationen <<execution environment>> Linux Attribute
+ distribution = SuSE 10 + boot() + shutdown() Operationen Sichtbarkeit Operation

235 Hierarchie von Knoten <<application server >>
Applikationsserver <<execution environment>> Tomcat <<artifact>> PdfErzeuger.class

236 Deploy-Abhängigkeit Ausführungsumgebung
<<application server>> Applikationsserver Artefact <<execution environment>> Tomcat Deploy-Abhängigkeit <<artifact>> PdfErzeuger.class <<deploy>>

237 Einsatzspezifikation
<<artefact>> erzeugePdf.jar <<execution environment>> Tomcat <<deploy>> <<deployment spec>> Web.xml + servlet-name: = erzeugePdf + servlet-class: = Hauptklasse

238 Deployment-Specs - Einsatz- bzw. Verteilungsspezifikationen

239 Einsatzspezifikation innerhalb eines Knotens
<<execution environment>> Tomcat Einsatzspezifikation <<deployment spec>> web.xml + servlet-name: = erzeugePdf + servlet-class: = Hauptklasse <<artifact>> erzeugePdf.jar

240 Einsatzspezifikation innerhalb eines Artefakts
<<execution environment>> Tomcat <<artifact>> erzeugePdf.jar {servlet-name: = erzeugePdf Servlet-class: = Hauptklasse}

241 Kommunikationspfad Rolle Kommunikationskanal
<<application server>> Applikationsserver <<client PC>> PC +Client +Server <<internet>> 1 1..* Multiplizität Kommunikationspfad

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

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

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

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

246 Quelle: http://casablanca. informatik. hu-berlin

247 Quelle: http://se. cs. uni-magdeburg

248 Verteilungsdiagramme als Erweiterung anderer UML-Diagrammtypen
Quelle:

249 Quelle: http://www3. informatik. uni-erlangen

250 Verteilungsbeziehung

251

252

253 Häufig gemachte Fehler

254 Häufig gemachte Fehler
(A): Richtung der <<deploy>> Abhängigkeit ist falsch B: (B): Abhängigkeit fehlt (C): Mehrfachknoten (D): Stereotyp fehlt (E): Kommunikationskanal fehlt

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

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

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

258

259

260 Ein „realistisches“ Beispiel

261

262

263

264

265

266

267 Die Object Constraint Language

268 Use Case Diagramm aufrufen
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.

269 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

270 Der Begriff OCL Entwicklung Begriffsabgrenzung Constraints
Definition Constrainttypen Beispiel an einem Klassendiagramm

271 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

272 Nutzerdefinierte Typen
Typkonformität Übung

273 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

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

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

276 Beispiel - Klassendiagramm

277

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

279 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

280 Erläuterte Constrainttypen
Invarianten Pre- & Postconditions Initial & Derived Value Package Context Operation Body Expression

281 Invarianten Definition:
Eine Invariante ist ein Constraint, das für ein Objekt während seiner ganzen Lebenszeit wahr sein sollte. Syntax: context Typename inv: Ausdruck

282 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 inv overAge: c.age >= 18

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

284 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

285 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 = …

286 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

287 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

288 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 * ( motorVehicle.age) / 100 else 0 endif

289 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

290 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

291 „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

292 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 Benutzerdefinierte Typen

293 Konstrukte der OCL Boolean Type Werte: true, false Operationen:

294 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 Client isMale implies title = ‘Mr.‘

295 Konstrukte der OCL Integer Type Wertebereich:
Menge der ganzen Zahlen ohne Obergrenze Operationen: Addition, Subtraktion, Multiplikation, Division Modulus, Integer Division, Absolutwert, Minimum.

296 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

297 Operationen für integer und real

298 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‘

299 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

300 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

301 Konstrukte der OCL Collection Type
Set: keine doppelten Elemente z.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 geordnet z.B.: Sequence{1,3,5,7,1} und Sequence{3,1,5,7,1} entsprechen sich nicht

302 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}

303 Konstrukte der OCL Collection Type - Operationen Collection Type

304

305 Konstrukte der OCL Operation „equals“ equals ergibt true, wenn
zwei Sets dieselben Elemente enthalten Set {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}

306 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

307 Konstrukte der OCL Operation „including“ hinzufügen von Elementen
bei Sets nur, wenn das Element noch nicht vorhanden ist Set{1,2,5,88}-> including({27,5}) = Set{1,2,5,88,27} bei einer Sequence wird am Ende eingefügt Sequence{1,2,5,88}-> including({27}) = Sequence{1,2,5,88,27}

308 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 entfernen Sequence{1,2,5,2,88}-> excluding({2}) = Sequence{1,5,88}

309 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}

310 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 sind Set{1,4,7,10}.symmetricDifference(Set{4,5,7}) = Set{1,5,10}

311 Konstrukte der OCL Spezielle Operationen für Sequence
„first“ bzw. „last“ Ausgabe des ersten bzw. letzten Elements Sequence{1,4,7,10} -> last = 10 Sequence{1,4,7,10} -> first = 1 „at()“ Element an der angegebenen Position Sequence{1,4,7,10} -> at(3) = 7 „append()“ bzw. „prepend()“ Einfügen an letzter bzw. erster Position Sequence{1,4,7,10} -> prepend(15) = Sequence{15,1,4,7,10}

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

313 Konstrukte der OCL Operationen für Elemente einer Collection „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

314 Konstrukte der OCL Operationen für Elemente einer Collection „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ß

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

316 Quelle: Schürr 2007

317 Nutzerdefinierte Typen
Durch den Benutzer definierte OCL-Typen neue Typen haben die gleiche Gültigkeit wie vordefinierte Typen Klassentypen Aufzählungstypen

318 Nutzerdefinierte Typen
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

319 Nutzerdefinierte Typen
Attribute Operationen und Methoden Klassenattribute Klassenoperationen Assoziationsenden („Navigationsausdrücke“)

320 Nutzerdefinierte Typen
Gültige Arten für Nutzerdefinition sind: Typen Klassen Interfaces Assoziationen Akteure Use Cases Datentypen

321 Nutzerdefinierte Typen
Klassenattribute im UML-Modell sind gültige Attribute im OCL. Beispiel: Customer self.name

322 Nutzerdefinierte Typen
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() >= 0

323 Nutzerdefinierte Typen
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

324 Nutzerdefinierte Typen
im UML ist Mehrfachvererbung möglich Problem: CassetteBook self.volume < 10 nicht eindeutig, ob volume von Book oder Cassette gemeint ist

325 Nutzerdefinierte Typen
Lösung: Das im OCL vorhandene pathname Konstrukt. Beispiel: CassetteBook self.Cassette::volume < 10

326 Nutzerdefinierte Typen
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 Customer gender = #male implies title = ´Mr.´

327 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

328 Typkonformität Type Konform zu/ Supertyp Set Sequence Bag Integer
Collection Real

329 Ü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)

330 Ü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() * 60) || (s2.getDatum() > s1.getDatum() * 60))

331 Ü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)

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

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

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

335 Verfahren der Qualitätssicherung
ISO 9000 TQM CMM / CMMI Bootstrap Spice

336 Exkurs: XP als Antithese zum SE

337 “Angeklagt: Agile Prozesse”
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... Am Wochenende bin ich beim Blättern in der “Delegate Information” zur Konferenz “Objekt-Orientiertes Programmieren OOP 2002” auf folgende Veranstaltung getroffen: ... Verrat, Umsturz, Totschlag. Harte Geschütze werden hier aufgefahren gegen den “Neuen Star des Software Engineering”, wie ein Leser des Buches bei einer Rezension es XP-Buches auf amazon.de schreibt. Was ist so revolutionär an Extreme Programming, was steckt dahinter, wie funktioniert XP? Darauf will ich in diesem Referat eingehen. Quelle: Delegate Information zur OOP 2002

338 Das Revolutionäre an XP
Ansätze Das 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.

339 Projektablauf im Vergleich
Planung Projektablauf im Vergleich Vorstudie Analyse Wasserfall- modell Design Konstruktion Test Einführung Zeit Release Design Story Implementierung Programming Extreme Planning Game Task Test Integration

340 Planung Planning 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 Iterationen

341 Planung Iterationsplanung
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.

342 Projektumfeld Arbeitsplä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.

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

344 Projektumfeld On-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).

345 Umsetzung Simple 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. zu Cost-of-Change-Kurve: - Kurve an Tafel malen und erklären: Kurve nähert sich Asymptote, da - Funkitonalität so spät wie möglich =nicht umsonst implementiert wird. - fehlerhafte Designänderungen durch Tests abgefangen werden => niedriges Risiko Cost of Change Extreme Programming herkömmliches Software Engineering

346 Umsetzung Testing 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 Operational Tests: um Interface, Implementierung zu prüfen müssen zu 100% durchlaufen Functional Tests: Realität: Kunde lässt schreiben Kunde muss Wichtigkeit einschätzen erst zu Ende 100%iger Erfolg nötig

347 Umsetzung Testing 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. Operational Tests: um Interface, Implementierung zu prüfen müssen zu 100% durchlaufen Functional Tests: Realität: Kunde lässt schreiben Kunde muss Wichtigkeit einschätzen erst zu Ende 100%iger Erfolg nötig

348 Umsetzung Pair 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.

349 Umsetzung 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.

350 Continous Integration
Umsetzung Continous 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.

351 Wann ist XP nicht sinnvoll?
Bewertung Wann 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.

352 Bewertung Wann ist XP sinnvoll?
Extreme Programming ist eine Überlegung wert, wenn... ... keiner der Punkte auf der vorherigen Folie zutrifft.

353 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) - weitergehende Informationen - Anwendungsbeispiele aus der Praxis


Herunterladen ppt "Folien zum Software Engineering"

Ähnliche Präsentationen


Google-Anzeigen