Grundlagen des Software Engineerings

1. Grundlagen des Software Engineerings Angebotserstellung Modellbasierte Softwareentwicklung Musterbasierte Softwareentwicklung Reverse Engineering

2. Zur Information • Webseite ist aktualisiert • Lastenheft, Vorlesungsfolien, Vorlagen, ... sind online • Alle sollten sich auf das erste Meeting vorbereiten, in dem sie / er das Lastenheft gründlich durcharbeitet • Kaola-Gruppe ist offen • Passwort kam via Mail Software(technik)praktikum: Vorlesung 1

3. SWTPra-Gruppenverteilung • Paul: 77 Teilnehmer • Moreganize: 7 Gruppen á 11 Stud., 70 Abstimmungen • Problem: Gruppe 7 zu wenig Studenten • Lösung 1: Von andere Gruppen abziehen • Lösung 2: Gruppe 7 auflösen und auf andere Gruppen verteilen  6 Gruppen mit 11 bzw. 12 Teilnehmern Neu Kann sich noch ändern. Software(technik)praktikum: Vorlesung 1

4. SWTPra-Gruppenverteilung • Paul: 30 Teilnehmer • Moreganize: 3 Gruppen á 10 Stud., 29 Abstimmungen Software(technik)praktikum: Vorlesung 1

5. Praxis-Tutorials • Feedback der Tutoren • Tutorials sind effektiver, wenn sie direkt innerhalb der Gruppe aufbereitet und durchgeführt werden • Dies war die letzten beiden Jahre sehr erfolgreich. • Fazit: • Es wird keine gruppenübergreifenden Tutorials geben • Bestimmen Sie innerhalb des Teams je Tutorial eine Person, die das Tutorial aufbereitet und mit der Gruppe durchführt • Für folgende Themen stellen wir Folien auf der Webseite bereit • Eclipse, SVN, Testen, Latex, GEF (GEF nur elevant für SWTPra) • Folgende Tutorial sind zusätzlich sinnvoll • Trac, EMF + OCL (vor allem SWTPra), Graphiti(relevant für SWTPra als Alternative zu GEF) • Sie können selbst entscheiden, welche Tutorials sie durchführen. Software(technik)praktikum: Vorlesung 1

6. Angebotserstellung

7. Ziel dieser Vorlesungseinheit • Im Praktikum sollten sie zunächst ein Angebot erstellen • Angebot setzt sich zusammen aus • Aufwandsschätzung • Projektplan • Angebot geschieht aufgrund des Lastenheftes • Ziel dieser Vorlesungseinheit • Wiederholung zum Lastenheft • Lernen, wie eine Aufwandsschätzung erfolgt • Schätzverfahren kennenlernen • Lernen, wie eine Projektplan erstellt wird

8. Lastenheft (grobes Pflichtenheft) • DIN 69901-5 • Vom Auftraggeber erstellt • Beschreibt seine Forderungen • Für Auftraggeber und -nehmer • Inhalt • Wesentliche Anforderungen des Produkts aus fachlicher Sicht (Anwendungsgebiet) • Wesentliche Funktionen & Daten • Liefert die Grundlage für • Aufwandsschätzung • Erstellung des Projektplans Ihr Lastenheft haben Sie bereits von uns erhalten. 8 Software(technik)praktikum: Vorlesung 4

9. Lastenheft (grobes Pflichtenheft) • Unser Lastenheft ist idealisiert • Ausführlich (20 Seiten) • Mehrere Reviewzyklen • Möglichst Konfliktfrei • In der Industrie werden Sie so ein Lastenheft leider nur selten finden • Diese sind meist • Sehr kurz (1-2 Seiten) • Ohne Reviews • Nicht konfliktfrei 9 Software(technik)praktikum: Vorlesung 4

10. Angebot • Aufbau: • Maximal 5 Seiten • Anschreiben (1 Seite) • Aufwandsschätzung (1 Seite) • Projektplan (1 Seite) • Erklärender Text (max. 2 Seiten) • Zur Aufwandsschätzung und dem Projektplan 10 Software(technik)praktikum: Vorlesung 4

11. Angebot • Tipps • Darstellung der Aufwände sollte übersichtlich sein • z.B. Tabellarisch • Arbeitspakete und Projektplan als Diagrammen visualisieren und textuell beschreiben • Keine Diagramme ohne erklärenden Text! • Verantwortliche mit Kontakt-Möglichkeit angeben • Auf Rechtschreibung, Ausdruck, Grammatik achten 11 Software(technik)praktikum: Vorlesung 4

12. Aufwandsschätzung • Auf der Basis des Lastenheftes, insbesondere der Produktfunktionen und der Produktdaten, lässt sich der Aufwand schätzen. • Meist wird die Größe des resultierenden Softwareprodukts geschätzt 12 Software(technik)praktikum: Vorlesung 4

13. Aufwandsschätzung • Schätzverfahren erfordern viel Erfahrung • Schätzverfahren benötigen Aufwandsdaten aus vorangegangenen Softwareprojekten • in ähnlichem Anwendungsgebiet • mit ähnlichen Entwicklungsmethoden • mit ähnlicher Firmenkultur • Sonst stimmt die Hypothese der „konstanten“ Produktivität nicht, die fast allen Verfahren zugrunde liegt Haben Sie nicht. Haben Sie auch nicht. 13 Software(technik)praktikum: Vorlesung 4

14. Aufwandsschätzung • Im Praktikum wird die Aufwandsschätzung nicht bewertet. • Um Erfahrung zu sammeln, sollen Sie aber die Grundlage Ihrer Schätzung und das Schätzergebnis am Ende mit dem Ergebnis und dem tatsächlichen Aufwand vergleichen • Stundenzettel • Zählen der LOC (SVN-Repository) • Vergleich im Abschlussdokument 14 Software(technik)praktikum: Vorlesung 4

15. Grundlegende Schätzmethoden Expertenmethode • Mehrere Experten schätzen unabhängig voneinander den Aufwand für jede Funktion. • Dann vergleichen und diskutieren sie die Resultate • Danach gibt jeder Experte nochmals eine Schätzung ab (ggf. wird iteriert). • Am Ende werden die Schätzungen gemittelt. ( Delphi,  XP) Bewertung: • relativ genaue Schätzung • Experten erforderlich 15 Software(technik)praktikum: Vorlesung 4

16. Grundlegende Schätzmethoden Analogiemethode Schätzung aufgrund der Ähnlichkeit des geplanten Produkts mit einem Produkt, das bereits früher erstellt wurde und für das der Aufwand bekannt ist Bewertung: + reale Basis • viel Erfahrung nötig • Mangel an vergleichbaren Projekten • Ähnlichkeit ist subjektiv • Abweichungen schlecht quantifizierbar 16 Software(technik)praktikum: Vorlesung 4

17. Grundlegende Schätzmethoden Multiplikationsmethode • Zerlegung des Produkts in Teilprodukte • Bewertung anhand vergleichbarer Teilprodukte Bewertung: + vergleichbare Teilprodukte sind eher vorhanden • Bewertung noch nicht in der Planungsphase möglich (Teilprodukte werden frühestens im Pflichtenheft definiert) 17 Software(technik)praktikum: Vorlesung 4

18. Grundlegende Schätzmethoden Gewichtungsmethode • Die Produktfunktionen werden kategorisiert und gemäß Komplexität klassifiziert. • Aus der Anzahl der jeweiligen Funktionen wird gemäß einer festen Rechenvorschrift ein Wert berechnet. • Dieser Wert wird über eine Tabelle (der gesammelten Erfahrungswerte) in den Aufwand übersetzt. (Bsp: Function-Point-Methode) Bewertung: + Schätzung in der Planungsphase + Schätzung ist nachvollziehbar + keine vergleichbaren Projekte nötig + Anpassbar an die eigene Firmenkultur und –methodik durch Anpassung der Tabelle + verfeinerte Schätzung bei verfeinerten Anforderungen möglich + Kochrezept, das (relativ) wenig Erfahrung erfordert - Hoher Aufwand Software(technik)praktikum: Vorlesung 4

19. Beispiel: Function-Point-Methode • Standardisiert in der ISO/IEC 20926 • Zerlegung des Systems in elementare, in sich abgeschlossene Funktionen aus Anwendersicht, z.B. • Erfassung einer Adresse • Berechnung eines Tarifs • Laden/Speichern • Function-Point-Bewertung ist unabhängig von der Technologie der Anwendung Function-Point-Methode ist zugeschnitten auf klassische Informationssysteme. Das Prinzip dahinter lässt sich aber auf andersartige Systeme übertragen. Software(technik)praktikum: Vorlesung 4

20. Beispiel: Function-Point-Methode • Kategorisierung, z.B. • Externe Ein- und Ausgaben, Benutzerinteraktionen, Externe Schnittstellen, Interne Dateien • Klassifizierung (der Komplexität), z.B: • einfach, mittel, komplex • Je Kategorie-Klassen-Kombination wird ein Punktwert zugewiesen • einfacheexterne Eingaben = 3 • für komplexeinterne Dateien = 15 • Funktionen werden einer Kategorie und Klasse zugeordnet • Jede Funktion hat somit einen Punktwert • Functional Size der Anwendung = Summe aller Punktwerte [Sommerville, Software Engineering, 1992] Software(technik)praktikum: Vorlesung 4

21. Beispiel: Function-Point-Methode • Bewertung weiterer Einflussfaktoren: • Verflechtung mit anderen Systemen • Verteilungsgrad der Daten • Wiederverwendung • Anpassbarkeit • … • Die weiteren Einflussfaktoren modifizieren die Bewertung (Functional Size) meist nicht mehr als +/- 30% • Das Ergebnis ist die Function-Point-Bewertung. Software(technik)praktikum: Vorlesung 4

22. Beispiel: Function-Point-Methode • Über eine Tabelle (mit bisherigen Erfahrungswerten des Unternehmens) werden die Function Points in den Aufwand umgerechnet • Nach Abschluss des Projekts wird die Tabelle aktualisiert Software(technik)praktikum: Vorlesung 4

23. Schätzverfahren • Es gibt viele verschiedene Basismethoden und noch mehr konkrete Verfahren • Konkrete Schätzverfahren kombinieren verschiedene Methoden, um deren Nachteile auszumerzen und das Schätzergebnis zu verbessern • Auch das ausgeklügeltste Verfahren kann die Erfahrung nicht ersetzen Software(technik)praktikum: Vorlesung 4

24. Aufwandsschätzung Positiv-Beispiel: tabellarisch ausführlich mit Std.-Lohn zusätzlich: beschreibender Text erledigt Hauptaufgaben Teilaufgaben noch zu tun Gesamtaufwand 24 Software(technik)praktikum: Vorlesung 4

25. Aufwandsschätzung Positiv-Beispiel: Preis muss nachvollziehbar sein Auftraggeber hat durch Gliederung die Möglichkeit, einzelne Punkte zu streichen Teilsummen 25 Software(technik)praktikum: Vorlesung 4

26. Projektplan • Orientiert sich am vorgegebenen Zeitplan • Projektplan detailliert den Zeitplan • Ggf. Zuordnung von Ressourcen (Personen) zu einzelnen Aktivitäten • Interne Meilensteine • Vorschläge für Aufgabenstart übernehmen oder anpassen • Berücksichtigt das gewählte Vorgehensmodell • ... 26 Software(technik)praktikum: Vorlesung 4

27. Einhaltung des V-Modells Ihr Projektplan soll sich ans V-Modell halten. Software(technik)praktikum: Vorlesung 4

28. Projektplan • Verschiedene Darstellungsformen möglich • Gantt-Diagramm • Aktivitätendiagramm • Tabelle • Mögliche Werkzeuge • Microsoft Project (Erhältlich via MSDNAA) • Gantt Project 28 Software(technik)praktikum: Vorlesung 4

29. Modellbasierte Softwareentwicklung

30. Motivation und Beispiel • Was sind „Softwaremodelle“? • Wozu sind sie gut? • Warum brauchen wir sie? • Was ist Software? • Was ist ein Modell? 30 Software(technik)praktikum: Vorlesung 4

31. Modell Modell [lat.-vulgärlat.-it.]das; -s, -e: … • die vereinfachte Darstellung der Funktion eines Gegenstands od. des Ablaufs eines Sachverhalts, die eine Untersuchung od. Erforschung erleichtert od. erst möglich macht. … [nach Duden: Das Fremdwörterbuch, 1990]. 31 Software(technik)praktikum: Vorlesung 4

32. Zweck von Modellen • Verständnis des Problembereichs und des Endproduktes • Kommunikation • auf richtiger Abstraktionsebene • mit verschiedenen Personengruppen • Abstraktion • Analyse & Verifikation • Konsistenz, Vollständigkeit,Korrektheit, … • Codegenerierung 32 Software(technik)praktikum: Vorlesung 4

33. Modell und Metamodell * PetriNet context Arc inv:( self.source.oclIsKindOf(Place) and self.target.oclIsKindOf(Transition) )or( self.source.oclIsKindOf(Transition) and self.target.oclIsKindOf(Place) ) Element 1 source Node Arc 1 target graphische / konkrete Syntax des Petrinetz-modells Transition Place Token * Abstrakte Syntax des Metamodells für Petrinetze 33 Software(technik)praktikum: Vorlesung 4

34. Abstrakte und konkrete Syntax :Petrinet source target graphische / konkrete Syntax :Arc :Place :Transition source target abstrakte Syntax(in Form eines Objektdiagramms) :Arc :Arc source target source target :Transition :Token :Place :Arc 34 Software(technik)praktikum: Vorlesung 4

35. Metamodell und Modell PetriNet :Petrinet * Element source target :Arc :Place :Transition target source 1 source Node Arc :Arc :Arc 1 target Transition Place Token source target target source :Transition :Token :Place :Arc * Tipp zur Metamodellierung: Erst über die Modellebene nachdenken! Also erst ein Objektdiagramm für ein repräsentatives Beispiel zeichnen und dann ein Klassendiagram erstellen. Metamodell ist Instanz von Modell konkrete Syntax abstrakte Syntax 35 Software(technik)praktikum: Vorlesung 4

36. Klassendiagramm als Modell PetriNet * Element 1 source Node Arc 1 target Transition Place Token * ClassDiagram * * 1 source Class Association 1 target UML-Modell Ausschnitt des Metamodells der UML (Klassendiagramme) 36 Software(technik)praktikum: Vorlesung 4

37. Überblick PetriNet :Petrinet … ClassDiagram * Element source target :Arc :Place :Transition :Association :Class :Class :Association * * target source 1 source … Class Association 1 source Node Arc 1 target :Arc :Arc 1 target Transition Place source Token target target source :Transition :Token :Place :Arc * Modell fürKlassendiagramme Meta-Meta-Modell Instanz von (alternativ: Meta-Modell) Modell für Petrinetze Abstrakte Syntax zu Meta-Modell (alternativ: Modell) Instanz von Abstrakte Syntax zu Ein Petrinetz Modell (alternativ: Instanz) 37 Software(technik)praktikum: Vorlesung 4

38. Modelle im Softwareentwurf • MOF: Meta-Object Facility (OMG Standard) beschreibt Level M3 Meta-Metamodell MOF MOF Instanz von Instanz von beschreibt (UML) Level M2 Metamodell UML Metamodell für Petrinetze beschreibt Instanz von Level M1 Modell Modell einesDame-Spiels Petri-Netz einer Ampel beschreibt Instanz von ein Dame-Spiel (z.B. Brettspiel oder Simulation im Computer) eine Ampel (in Wirklichkeit oder deren Simulation im Computer) Level M0 Instanz/Wirklichkeit 38 Software(technik)praktikum: Vorlesung 4

39. Modelle im Softwareentwurf • MOF: Meta-Object Facility (OMG Standard) Man kann ein Metamodell für Petrinetze in UML beschreiben oder direkt in MOF. Nehmen wir UML, dann haben wir mehr als vier Meta-Ebenen. beschreibt Level M3 Meta-Metamodell MOF MOF Instanz von Instanz von beschreibt (UML) Begriffe: Metamodell nennen wir das Modell einer Sprache, mit der sich wiederum weitere Modelle beschreiben lassen. Die Modelle, die UML und Petrinetze beschreiben sind also Metamodelle. Das Modell eines Damespiels ist demnach kein Modell. Man kann allerdings argumentieren… Level M2 Metamodell UML Metamodell für Petrinetze beschreibt Instanz von Level M1 Modell Modell einesDame-Spiels Petri-Netz einer Ampel beschreibt Instanz von ein Dame-Spiel (z.B. Brettspiel oder Simulation im Computer) eine Ampel (in Wirklichkeit oder deren Simulation im Computer) Level M0 Instanz/Wirklichkeit 39 Software(technik)praktikum: Vorlesung 4

40. Modelle im Softwareentwurf • „Traditionell“: Mehr oder weniger automatisch: • Forward-Engineering • Reverse-Engineering • Re-Engineering • Model DrivenArchitecture (MDA) • Generierung von (Teilen der)Software aus Modellen  Modelle sind die Software 40 Software(technik)praktikum: Vorlesung 4

41. „Traditionell“ Zunächst: Informelle Skizzen zur Diskussion, zum Verständnis und Kommunikation von Ideen und Entwürfen. Später: Standardisierte (graphische) Notationen. Aus diesen Diagrammen wurde dann (meist manuell) der Code erzeugt! Forward-Engineering 41 Software(technik)praktikum: Vorlesung 4

42. „Traditionell“ • Da Software oft nicht dokumentiert ist, wurde es nötig, aus existierendem Programmcode die Ideen, die dem Code zugrunde liegen, als Modelle zu extrahieren. • Diese Modelle dienen dem Verständnis der existierenden Software! Auf Ihrer Basis kann die Software geändert und verbessert werden. Reverse-Engineering Re-Engineering = Reverse- & Forward-Engineering 42 Software(technik)praktikum: Vorlesung 4

43. Automatisierung • Teilweise lassen sich Reverse- und Forward-Engineering automatisieren (im Wesentlichen Struktur). • Änderungen an durch Reverse-Engineering erstellten Modellen können wieder in den Code übertragen werden. Roundtrip-Engineering 43 Software(technik)praktikum: Vorlesung 4

44. Musterbasierte Softwareentwicklung

45. Übersicht • Architekturstile / bzw. Architekturmuster und Entwurfsmuster unterstützen bei der Realisierung von Software • Eclipse und insbesondere das GraphicalEditing Framework (GEF) nutzen diese und leiten zu deren richtigen Nutzung an • Ziel dieser Vorlesungseinheit: • Wiederholung des bereits gelernten aus GP2 und SE • Anwendung des Model-View-Controller Architekturstils bei GEF • GEF: Framework zur Entwicklung von graphischen Editoren und Sichten in der Eclipse Plattform Wir empfehlen GEF für die Entwicklung der Komponenten Spielkonfigurator und PC-Beobachter.

46. Erinnerung: Entwurfsmuster (Design Patterns) • Beschreibungen für wiederkehrende Softwareentwicklungsaufgaben • Sind wiederverwendbare objektorientierte Schemata (Struktur und Verhalten) • Sind erprobt, erhöhen Wartbarkeit, Flexibilität, Adaptierbarkeit, Verständlichkeit, … • Die bekanntesten 23 Entwurfsmuster sind beschrieben in Design Pattern – Elements ofReusableObject-oriented Software, Gamma et al., 1995 Bekannt aus der Vorlesung Softwareentwurf 46 Software(technik)praktikum: Vorlesung 4

47. Erinnerung: Entwurfsmuster (Design Patterns) • In Eclipse, GEF und der Java-Bibliothek werden zahlreiche Entwurfsmuster verwendet. • Einige Muster nach Gamma et al.: • Observer (Beobachten von Änderungen, z.B. in GEF) • Adapter (Anpassen der Schnittstelle, z.B. in Eclipse) • Command (Kapseln von Änderungen, z.B. in GEF) • Singleton (Nur eine Instanz einer Klasse erlauben) • Strategy (Umschalten zwischen versch. Algorithmen) Mehr hierzu in der Vorlesung „Modellbasierte Softwareentwicklung“ im Wintersemester Nutzen Sie Entwurfsmuster im Praktikum. 47 Software(technik)praktikum: Vorlesung 4

48. Erinnerung: Architekturstile • Bekannte Architekturstile • Schichtenarchitektur • Model – View – Controller • Web-Service-orientierte Architektur Bekannt aus der Vorlesung Softwareentwurf

49. Model-View-Controller :GraphEditPart :TransitionEditPart :PlaceEditPart :TransitionEditPart :PlaceEditPart • Modelländerung aufgrund Benutzerinteraktion • Aktualisierung der Darstellung nach Modelländerung Controller Darstellung des Modells & Interaktion mit Benutzer Fachmodell (Daten) & Funktionen darauf :Petrinet :Transition :Arc :Place Wenn Model & View unabhängig voneinander sind, sind beide leicht änderbar :Arc :Arc View :Transition :Token :Place :Arc Model 49 Software(technik)praktikum: Vorlesung 4

50. GEF nutzt Model-View-Controller :GraphEditPart :TransitionEditPart :PlaceEditPart :TransitionEditPart :PlaceEditPart Controller In GEF: EditParts :Petrinet :Transition :Arc :Place :Arc :Arc View In GEF: Figures :Transition :Token :Place :Arc Model In GEF: EObjects 50 Software(technik)praktikum: Vorlesung 4