Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Angebotserstellung Modellbasierte Softwareentwicklung Musterbasierte Softwareentwicklung.

Ähnliche Präsentationen


Präsentation zum Thema: "© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Angebotserstellung Modellbasierte Softwareentwicklung Musterbasierte Softwareentwicklung."—  Präsentation transkript:

1 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Angebotserstellung Modellbasierte Softwareentwicklung Musterbasierte Softwareentwicklung Reverse Engineering Grundlagen des Software Engineerings

2 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Angebotserstellung

3 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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

4 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Lastenheft (grobes Pflichtenheft) DIN 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 4 Software(technik)praktikum: Vorlesung 4 Ihr Lastenheft haben Sie bereits von uns erhalten.

5 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 5 Software(technik)praktikum: Vorlesung 4

6 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 6 Software(technik)praktikum: Vorlesung 4

7 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 7 Software(technik)praktikum: Vorlesung 4

8 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 8 Software(technik)praktikum: Vorlesung 4

9 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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. 9 Software(technik)praktikum: Vorlesung 4

10 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 10 Software(technik)praktikum: Vorlesung 4

11 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 11 Software(technik)praktikum: Vorlesung 4

12 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 12 Software(technik)praktikum: Vorlesung 4

13 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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) 13 Software(technik)praktikum: Vorlesung 4

14 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 14 Software(technik)praktikum: Vorlesung 4

15 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Beispiel: Function-Point- Methode Standardisiert in der ISO/IEC 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 15 Software(technik)praktikum: Vorlesung 4 Function-Point-Methode ist zugeschnitten auf klassische Informationssysteme. Das Prinzip dahinter lässt sich aber auf andersartige Systeme übertragen.

16 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 einfache externe Eingaben = 3 für komplexe interne Dateien = 15 Funktionen werden einer Kategorie und Klasse zugeordnet Jede Funktion hat somit einen Punktwert Functional Size der Anwendung = Summe aller Punktwerte 16 [Sommerville, Software Engineering, 1992] Software(technik)praktikum: Vorlesung 4

17 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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. 17 Software(technik)praktikum: Vorlesung 4

18 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 18 Software(technik)praktikum: Vorlesung 4

19 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 19 Software(technik)praktikum: Vorlesung 4

20 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Aufwandsschätzung Positiv-Beispiel: tabellarisch ausführlich mit Std.-Lohn zusätzlich: beschreibender Text erledigt noch zu tun Teilaufgaben Gesamtaufwand Hauptaufgaben 20 Software(technik)praktikum: Vorlesung 4

21 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Aufwandsschätzung Positiv-Beispiel: Preis muss nachvollziehbar sein Auftraggeber hat durch Gliederung die Möglichkeit, einzelne Punkte zu streichen Teilsummen 21 Software(technik)praktikum: Vorlesung 4

22 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 Software(technik)praktikum: Vorlesung 4

23 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Einhaltung des V-Modells 23 Ihr Projektplan soll sich ans V-Modell halten. Software(technik)praktikum: Vorlesung 4

24 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Projektplan Verschiedene Darstellungsformen möglich Gantt-Diagramm Aktivitätendiagramm Tabelle Mögliche Werkzeuge Microsoft Project (Erhältlich via MSDNAA) Gantt Project 24 Software(technik)praktikum: Vorlesung 4

25 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Modellbasierte Softwareentwicklung

26 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Motivation und Beispiel Was sind Softwaremodelle? Wozu sind sie gut? Warum brauchen wir sie? Was ist Software? Was ist ein Modell? 26 Software(technik)praktikum: Vorlesung 4

27 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Modell Modell [lat.-vulgärlat.-it.] das; -s, -e: … 7.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]. 27 Software(technik)praktikum: Vorlesung 4

28 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 28 Software(technik)praktikum: Vorlesung 4

29 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Modell und Metamodell graphische / konkrete Syntax des Petrinetz- modells PlaceTransition 1 source 1 target Arc * PetriNet context Arc inv: (self.source.oclIsKindOf(Place) and self.target.oclIsKindOf(Transition) ) or (self.source.oclIsKindOf(Transition) and self.target.oclIsKindOf(Place) ) Token * Node Element Abstrakte Syntax des Metamodells für Petrinetze 29 Software(technik)praktikum: Vorlesung 4

30 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Abstrakte und konkrete Syntax :Place :Transition :Arc :Transition :Place :Arc source target source target source :Arc source target :Petrinet :Token graphische / konkrete Syntax abstrakte Syntax (in Form eines Objektdiagramms) 30 Software(technik)praktikum: Vorlesung 4

31 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Metamodell und Modell :Place :Transition :Arc :Transition :Place :Arc source targetsource target source :Arc sourcetarget :Petrinet :Token PlaceTransition 1 source 1 target Arc * PetriNet Token * Node Element Modell Metamodell ist Instanz von konkrete Syntaxabstrakte Syntax 31 Software(technik)praktikum: Vorlesung 4 Tipp zur Metamodellierung: Erst über die Modellebene nachdenken! Also erst ein Objektdiagramm für ein repräsentatives Beispiel zeichnen und dann ein Klassendiagram erstellen.

32 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Klassendiagramm als Modell 1 source 1 target AssociationClass ClassDiagram Ausschnitt des Metamodells der UML (Klassendiagramme) UML-Modell PlaceTransition 1 source 1 target Arc * PetriNet Token * Node Element ** 32 Software(technik)praktikum: Vorlesung 4

33 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Überblick :Place :Transition :Arc :Transition :Place :Arc source targetsource target source :Arc sourcetarget :Petrinet :Token PlaceTransition 1 source 1 target Arc * PetriNet Token * Node Element 1 source 1 target AssociationClass ClassDiagram ** :Class :Association … … Abstrakte Syntax zu Ein Petrinetz Modell für Petrinetze Abstrakte Syntax zu Modell für Klassendiagramme Modell Meta-Modell Meta-Meta-Modell (alternativ: Instanz) (alternativ: Modell) (alternativ: Meta-Modell) Instanz von 33 Software(technik)praktikum: Vorlesung 4

34 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Modelle im Softwareentwurf MOF: Meta-Object Facility (OMG Standard) Level M3 Meta-Metamodell Level M2 Metamodell Level M1 Modell Level M0 Instanz/Wirklichkeit beschreibt Instanz von beschreibt MOF UML Modell eines Dame-Spiels ein Dame-Spiel (z.B. Brettspiel oder Simulation im Computer) MOF (UML) Petri-Netz einer Ampel eine Ampel (in Wirklichkeit oder deren Simulation im Computer) Metamodell für Petrinetze 34 Software(technik)praktikum: Vorlesung 4

35 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Modelle im Softwareentwurf MOF: Meta-Object Facility (OMG Standard) Level M3 Meta-Metamodell Level M2 Metamodell Level M1 Modell Level M0 Instanz/Wirklichkeit beschreibt Instanz von beschreibt MOF UML Modell eines Dame-Spiels ein Dame-Spiel (z.B. Brettspiel oder Simulation im Computer) MOF (UML) Petri-Netz einer Ampel eine Ampel (in Wirklichkeit oder deren Simulation im Computer) Metamodell für Petrinetze 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. 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… 35 Software(technik)praktikum: Vorlesung 4

36 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Modelle im Softwareentwurf Traditionell: Mehr oder weniger automatisch: Forward-Engineering Reverse-Engineering Re-Engineering Model Driven Architecture (MDA) Generierung von (Teilen der) Software aus Modellen Modelle sind die Software 36 Software(technik)praktikum: Vorlesung 4

37 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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! 37 Forward-Engineering 37 Software(technik)praktikum: Vorlesung 4

38 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 38 Software(technik)praktikum: Vorlesung 4

39 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 39 Software(technik)praktikum: Vorlesung 4

40 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Musterbasierte Softwareentwicklung

41 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Übersicht Architekturstile / bzw. Architekturmuster und Entwurfsmuster unterstützen bei der Realisierung von Software Eclipse und insbesondere das Graphical Editing 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 41 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.

42 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 of Reusable Object-oriented Software, Gamma et al., Software(technik)praktikum: Vorlesung 4 Bekannt aus der Vorlesung Softwareentwurf

43 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 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 43 Software(technik)praktikum: Vorlesung 4 Nutzen Sie Entwurfsmuster im Praktikum!

44 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Erinnerung: Architekturstile Bekannte Architekturstile Schichtenarchitektur Model – View – Controller Web-Service-orientierte Architektur 44 Bekannt aus der Vorlesung Softwareentwurf

45 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Model-View-Controller View Model :Place :Transition :Arc :Transition :Place :Arc :Petrinet :Token :PlaceEditPart:TransitionEditPart :PlaceEditPart :GraphEditPart Controller 45 Software(technik)praktikum: Vorlesung 4 Wenn Model & View unabhängig voneinander sind, sind beide leicht änderbar Fachmodell (Daten) & Funktionen darauf Darstellung des Modells & Interaktion mit Benutzer Modelländerung aufgrund Benutzerinteraktion Aktualisierung der Darstellung nach Modelländerung

46 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn GEF nutzt Model-View-Controller In GEF: Figures In GEF: EObjects In GEF: EditParts View Model :Place :Transition :Arc :Transition :Place :Arc :Petrinet :Token :PlaceEditPart:TransitionEditPart :PlaceEditPart :GraphEditPart Controller 46 Software(technik)praktikum: Vorlesung 4

47 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn GEF nutzt MVC EObjects Figures EditParts 2. EditPartViewer erstellt Request Editor 1. Aktion Command 3. erzeugt 4. modifiziert 5. erzeugt propertyChange Ereignisse 6. aktualisiert 47 Software(technik)praktikum: Vorlesung 4 Request Mehr dazu in unserem Tutorium: Einführung in GEF

48 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Zusammenfassung Architekturstile / -muster und Entwurfsmuster sind Ihnen bereits aus GP2 und SE bekannt Im Praktikum sollen Sie Architekturstile / -muster und Entwurfsmuster möglichst häufig nutzen Zum Teil wird deren Einsatz sogar erzwungen (z.B. GEF) Überlegen Sie beim Entwurf Ihrer Architektur und ihrer Implementierung, ob es für Ihre Entwurfsprobleme bereits bewährte Muster gibt. Wenn ja, nutzen Sie es. 48

49 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Reverse Engineering 49 Software(technik)praktikum: Vorlesung 4

50 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Reverse Engineering Software... wird heute nicht mehr isoliert eingesetzt muss mit anderer Software interagieren muss oft weiterentwickelt nachdem sie ausgeliefert wurde ist oft schlecht oder gar nicht dokumentiert Bevor man bestehende Software nutzen oder ändern kann, muss man sie verstehen bzw. rekonstruieren. 50 Software(technik)praktikum: Vorlesung 4

51 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Szenario im Praktikum SWTPra-Teams sollen auf der Messe einen Smartphone- Beobachter von den SoPra-Teams erwerben und erweitern, sodass damit ein Mensch spielen kann Frage: Worauf sollten SoPra-Teams bei der Erstellung achten? Worauf sollten SwtPra-Teams bei der Auswahl achten? 51 Auswahlkriterien?

52 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Wartung von Software Verstehen von Altsoftware ist sehr kostenintensiv 52 [Som12] Rebecca Tiarks: What Maintenance Programmers Really Do: An Observational Study

53 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Reverse Engineering Definition Unter Reverse Engineering versteht man den Prozess, die einem fertigen (und meist schlecht dokumentierten) Softwaresystem zugrunde liegenden Ideen und Konzepte aufzuspüren und (in Form von Modellen) zu dokumentieren. Entwicklungsprozess wird rückwärts durchlaufen Das Ergebnis des Reverse-Engineering ist (im Idealfall) eine Spezifikation des Softwaresystems. Wichtig: Abstraktion und Konzentration auf das Wesentliche 53 Software(technik)praktikum: Vorlesung 4

54 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Werkzeuggestütztes Reverse Engineering Werkzeuge können das Reverse-Engineering unterstützen! Aber sie können uns das Abstrahieren und die Auswahl des Wesentlichen nicht abnehmen. Dies ist die Aufgabe des Entwicklers. Heutige Werkzeuge liefern oft falsche Ergebnisse Diese müssen erkannt und von Hand korrigiert werden 54 Software(technik)praktikum: Vorlesung 4

55 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 55 Vom Code zum Modell A public class A { private String name; B anAttribute; … public void doThis() { … } } B - name : String + doThis() : void anAttribute Primitive Datentypen (int, String, …) werden als Attribut in der Klasse dargestellt (hier name), andere Variablen werden als Assoziationen zu den verwendeten Klassen dargestellt (hier B) 55 Software(technik)praktikum: Vorlesung 4

56 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 56 Beispiel: Code public interface Moveable { public void move(); } public abstract class Element {... } public class Track extends Element { private Track next; private Track prev; public Track getNext() { return this.next; } public void setNext(Track value) { if (this.next != value) { if (this.next != null) { Track oldValue = this.next; this.next = null; oldValue.setPrev (null); } this.next = value; if (value != null) { value.setPrev (this); } public Track getPrev() { return this.prev; } public void setPrev(Track value) { if (this.prev != value) { if (this.prev != null) { Track oldValue = this.prev; this.prev = null; oldValue.setNext (null); } this.prev = value; if (value != null) { value.setNext (this); } public class Shuttle extends Element implements Moveable { private boolean driving; private Track at; private Simulation simulation; public Track getAt() { return this.at; } public void setAt(Track value) { if ((this.at == null && value != null) || (this.at != null && !this.at.equals(value))) { this.at = value; } public boolean isDriving() { return this.driving; } public void setDriving(boolean value) { this.driving = value; } public Simulation getSimulation() { return this.simulation; } public void setSimulation(Simulation value) { if (this.simulation != value) { if (this.simulation != null) { Simulation oldValue = this.simulation; this.simulation = null; oldValue.removeFromShuttles (this); } this.simulation = value; if (value != null) { value.addToShuttles (this); } public void move() {... } public class Simulation { private TreeSet shuttles = new TreeSet(); public void addToShuttles(Shuttle value) { if (value != null) { boolean changed = this.shuttles.add (value); if (changed) { value.setSimulation (this); } public Iterator iteratorOfShuttles() { return this.shuttles.iterator (); } public void removeFromShuttles(Shuttle value) { if (value != null) { boolean changed = this.shuttles.remove (value); if (changed) { value.setSimulation (null); } public boolean hasInShuttles(Shuttle value) {... } public int sizeOfShuttles() {... } public void removeAllFromShuttles() {... } Was von diesem Code ist für das Verständnis relevant? 56 Software(technik)praktikum: Vorlesung 4

57 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Bsp.: generiertes Klassendiagramm Simulation - shuttles: TreeSet + addToShuttles(Shuttle) : void + iteratorOfShuttles() : Iterator + removeFromShuttles(Shuttle) : void + hasInShuttles(Shuttle) : boolean + sizeOfShuttles() : int + removeAllFromShuttles() : void Shuttle - driving : boolean - at : Track - simulation : Simulation + getAt() : Track + setAt(Track) : void + isDriving() : boolean + setDriving(boolean) : void + getSimulation() : Simulation + setSimulation(Simulation) : void + move() : void Track - next : Track - prev : Track + getNext() : Track + setNext(Track) : void + getPrev() : Track + setPrev(Track) : void Element «interface» Movable + move() : void «implements» 57 Software(technik)praktikum: Vorlesung 4

58 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Automatisch generierte Diagramme Problem: Automatisch generierte Modelle und deren Diagramme sind zwar meist syntaktisch korrekt, jedoch noch deutlich verbesserungswürdig Enthalten oft keine Kardinalitäten und Rollen Attribute, Methoden und Assoziationen sind redundant enthalten Unwichtige Informationen Alle Informationen in einem Diagramm, was sehr unübersichtlich sein kann Fazit: Manuelle Nachbearbeitung oftmals notwendig 58 Software(technik)praktikum: Vorlesung 4

59 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Beispiel: Ergebnis (Struktur) Manuell nachbearbeitetes Ergebnis: Simulation Shuttle + driving : boolean + move() : void Element «interface» Movable + move() : void «implements» simulationshuttles *0..1 at Track prev next Software(technik)praktikum: Vorlesung 4

60 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn 60 Nochmal im Vergleich: Code public interface Moveable { public void move(); } public abstract class Element {... } public class Track extends Element { private Track next; private Track prev; public Track getNext() { return this.next; } public void setNext(Track value) { if (this.next != value) { if (this.next != null) { Track oldValue = this.next; this.next = null; oldValue.setPrev (null); } this.next = value; if (value != null) { value.setPrev (this); } public Track getPrev() { return this.prev; } public void setPrev(Track value) { if (this.prev != value) { if (this.prev != null) { Track oldValue = this.prev; this.prev = null; oldValue.setNext (null); } this.prev = value; if (value != null) { value.setNext (this); } public class Shuttle extends Element implements Moveable { private boolean driving; private Track at; private Simulation simulation; public Track getAt() { return this.at; } public void setAt(Track value) { if ((this.at == null && value != null) || (this.at != null && !this.at.equals(value))) { this.at = value; } public boolean isDriving() { return this.driving; } public void setDriving(boolean value) { this.driving = value; } public Simulation getSimulation() { return this.simulation; } public void setSimulation(Simulation value) { if (this.simulation != value) { if (this.simulation != null) { Simulation oldValue = this.simulation; this.simulation = null; oldValue.removeFromShuttles (this); } this.simulation = value; if (value != null) { value.addToShuttles (this); } public void move() {... } public class Simulation { private TreeSet shuttles = new TreeSet(); public void addToShuttles(Shuttle value) { if (value != null) { boolean changed = this.shuttles.add (value); if (changed) { value.setSimulation (this); } public Iterator iteratorOfShuttles() { return this.shuttles.iterator (); } public void removeFromShuttles(Shuttle value) { if (value != null) { boolean changed = this.shuttles.remove (value); if (changed) { value.setSimulation (null); } public boolean hasInShuttles(Shuttle value) {... } public int sizeOfShuttles() {... } public void removeAllFromShuttles() {... } 60 Software(technik)praktikum: Vorlesung 4

61 © Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Zusammenfassung Ausgelieferte Software ist oft schwer zu verstehen und muss oft aufwändig Reverse Engineered werden Hochwertige Modelle, Dokumente und Code helfen enorm beim Verstehen dieser Software Ziel sollte es sein, dass Reverse Engineering nicht notwendig ist bzw. möglichst kurz ist Fazit für das Szenario im Praktikum: Der Smartphone-Beobachter sollten nicht nur funktionsfähig sein, sondern auch eine erweiterbare Architektur haben, gute dokumentierten Code besitzen und in hochwertige Dokumente beschrieben sein. 61


Herunterladen ppt "© Fachgebiet Softwaretechnik, Heinz Nixdorf Institut, Universität Paderborn Angebotserstellung Modellbasierte Softwareentwicklung Musterbasierte Softwareentwicklung."

Ähnliche Präsentationen


Google-Anzeigen