Grundlagen des Software Engineerings

Grundlagen des Software Engineerings
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 Grundlagen des Software Engineerings Angebotserstellung Modellbasierte Softwareentwicklung Musterbasierte Softwareentwicklung Reverse Engineering Letzte Woche Software-Management, jetzt Software-Engineering

Softwaretechnikpraktikum SS 2008: Vorlesung 3
21. April 2008 Angebotserstellung

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

Lastenheft (grobes Pflichtenheft)
Softwaretechnikpraktikum SS 2008: Vorlesung 3 Lastenheft (grobes Pflichtenheft) 21. April 2008 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 Muss normalerweise durch Besprechungen mit dem Kunden erstellt werden Ihr Lastenheft haben Sie bereits von uns erhalten. 4 Software(technik)praktikum: Vorlesung 4

Lastenheft (grobes Pflichtenheft)
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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 Muss normalerweise durch Besprechungen mit dem Kunden erstellt werden 5 Software(technik)praktikum: Vorlesung 4

Angebot Aufbau: Maximal 5 Seiten Anschreiben (1 Seite)
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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 6

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 7

Aufwandsschätzung Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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

Aufwandsschätzung Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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

Aufwandsschätzung Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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

Grundlegende Schätzmethoden
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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 Schätzklausur 11 Software(technik)praktikum: Vorlesung 4

Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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 Abweichungen z.B. andere Programmiersprache 12 Software(technik)praktikum: Vorlesung 4

Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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

Softwaretechnikpraktikum SS 2008: Vorlesung 3 Grundlegende Schätzmethoden 21. April 2008 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 Analogie: m² Wohnfläche = # Function Points, Kosten pro m² = Kosten der Entwicklung für einen FP der geforderten Qualität Software(technik)praktikum: Vorlesung 4

Beispiel: Function-Point-Methode
Softwaretechnikpraktikum SS 2008: Vorlesung 3 Beispiel: Function-Point-Methode 21. April 2008 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

Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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 FP benutzt statistische Methoden um Werte für einzelne Funktionstypen festzulegen FP durch FP-Usergruppen aktuell gehalten [Sommerville, Software Engineering, 1992] Software(technik)praktikum: Vorlesung 4

Softwaretechnikpraktikum SS 2008: Vorlesung 3 Beispiel: Function-Point-Methode 21. April 2008 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

Softwaretechnikpraktikum SS 2008: Vorlesung 3 Beispiel: Function-Point-Methode 21. April 2008 Über eine Tabelle (mit bisherigen Erfahrungswerten des Unternehmens) werden die Function Points in den Aufwand umgerechnet Nach Abschluss des Projekts wird die Tabelle aktualisiert IBM-Kurve Software(technik)praktikum: Vorlesung 4

Schätzverfahren 21. April 2008 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

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

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

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 ... 22 Software(technik)praktikum: Vorlesung 4

Einhaltung des V-Modells
Softwaretechnikpraktikum 2008: Vorlesung 5 Einhaltung des V-Modells 19. Mai 2008 Ihr Projektplan soll sich ans V-Modell halten. Software(technik)praktikum: Vorlesung 4

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

Modellbasierte Softwareentwicklung
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 Modellbasierte Softwareentwicklung

Motivation und Beispiel
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 Was sind „Softwaremodelle“? Wozu sind sie gut? Warum brauchen wir sie? Was ist Software? Was ist ein Modell? 26 Software(technik)praktikum: Vorlesung 4

Modell Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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]. 27 Software(technik)praktikum: Vorlesung 4

Zweck von Modellen Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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

Modell und Metamodell Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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 29 Software(technik)praktikum: Vorlesung 4

Abstrakte und konkrete Syntax
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 :Petrinet source target graphische / konkrete Syntax :Transition :Arc :Place target source abstrakte Syntax (in Form eines Objektdiagramms) :Arc :Arc source target target source :Token :Place :Arc :Transition 30 Software(technik)praktikum: Vorlesung 4

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

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

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

Modelle im Softwareentwurf
Softwaretechnikpraktikum SS 2008: Vorlesung 3 Modelle im Softwareentwurf 21. April 2008 MOF: Meta-Object Facility (OMG Standard) beschreibt Level M3 Meta-Metamodell MOF MOF Instanz von beschreibt Instanz von Level M2 Metamodell (UML) UML Metamodell für Petrinetze beschreibt Instanz von Level M1 Modell Modell eines Dame-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 34 Software(technik)praktikum: Vorlesung 4 34

Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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 beschreibt Instanz von (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 eines Dame-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 35 Software(technik)praktikum: Vorlesung 4 35

Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 „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

„Traditionell“ Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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 37 Software(technik)praktikum: Vorlesung 4

„Traditionell“ Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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

Automatisierung Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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

Musterbasierte Softwareentwicklung
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 Musterbasierte Softwareentwicklung

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

Erinnerung: Entwurfsmuster (Design Patterns)
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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., 1995 Bekannt aus der Vorlesung Softwareentwurf 42 Software(technik)praktikum: Vorlesung 4

Erinnerung: Entwurfsmuster (Design Patterns)
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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) Nutzen Sie Entwurfsmuster im Praktikum! Mehr hierzu in der Vorlesung „Modellbasierte Softwareentwicklung“ im Wintersemester 43 Software(technik)praktikum: Vorlesung 4

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

Model-View-Controller
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 Modelländerung aufgrund Benutzerinteraktion Aktualisierung der Darstellung nach Modelländerung Controller :PlaceEditPart :TransitionEditPart :GraphEditPart 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 :Token :Place :Arc :Transition Model 45 Software(technik)praktikum: Vorlesung 4

GEF nutzt Model-View-Controller
Softwaretechnikpraktikum SS 2008: Vorlesung 3 GEF nutzt Model-View-Controller 21. April 2008 Controller :PlaceEditPart :TransitionEditPart :GraphEditPart In GEF: EditParts :Petrinet :Transition :Arc :Place :Arc :Arc View In GEF: Figures :Token :Place :Arc :Transition Model In GEF: EObjects 46 Software(technik)praktikum: Vorlesung 4

GEF nutzt MVC Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 EditParts Command 2. EditPartViewer erstellt Request 3. erzeugt Request 4. modifiziert 1. Aktion 6. aktualisiert EObjects Figures 5. erzeugt propertyChange Ereignisse The user acts on the view via the keyboard or mouse. GEF’s EditPartViewer determines what tool is being used and fires the appropriate request. The EditParts determine if they can create a corresponding command for that request The command is added to the command stack and executed, modifying the model The model fires the appropriate property change events after it has been modified EditParts update depending on what property changes are triggered. (For instance a new instance of a model element will trigger the EditPart Factory to instantiate a new corresponding EditPart) The EditParts update the view according to their new state. Luckily this whole process is handled by the GEF infrastructure. By creating/extending instances of the GraphicalEditorPartWithPalette, Commands, and EditPolicies you can create a the core of a GEF/MVC application. Editor Mehr dazu in unserem Tutorium: Einführung in GEF 47 Software(technik)praktikum: Vorlesung 4

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.

21. April 2008 Reverse Engineering 49 Software(technik)praktikum: Vorlesung 4

Reverse Engineering Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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

Szenario im Praktikum Frage:
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? Auswahlkriterien?

Wartung von Software Verstehen von Altsoftware ist sehr kostenintensiv
[Som12] Rebecca Tiarks: What Maintenance Programmers Really Do: An Observational Study

Reverse Engineering Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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

Werkzeuggestütztes Reverse Engineering
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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

Vom Code zum Modell Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 21. April 2008 public class A { private String name; B anAttribute; … public void doThis() { } A - name : String + doThis() : void anAttribute B 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 55 Software(technik)praktikum: Vorlesung 4 55

Beispiel: Code Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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) { boolean changed = this.shuttles.remove (value); value.setSimulation (null); public boolean hasInShuttles(Shuttle value) { ... public int sizeOfShuttles() { public void removeAllFromShuttles() { 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 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; value.setNext (this); Was von diesem Code ist für das Verständnis relevant? 56 Software(technik)praktikum: Vorlesung 4

Bsp.: generiertes Klassendiagramm
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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 «implements» 57 Software(technik)praktikum: Vorlesung 4

Automatisch generierte Diagramme
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 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

Beispiel: Ergebnis (Struktur)
Softwaretechnikpraktikum SS 2008: Vorlesung 3 21. April 2008 Manuell nachbearbeitetes Ergebnis: Simulation Shuttle + driving : boolean + move() : void Element «interface» Movable «implements» simulation shuttles 0..1 0..* at Track prev next 59 Software(technik)praktikum: Vorlesung 4

Nochmal im Vergleich: Code
Softwaretechnikpraktikum SS 2008: Vorlesung 3 Nochmal im Vergleich: Code 21. April 2008 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) { boolean changed = this.shuttles.remove (value); value.setSimulation (null); public boolean hasInShuttles(Shuttle value) { ... public int sizeOfShuttles() { public void removeAllFromShuttles() { 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 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; value.setNext (this); 60 60 Software(technik)praktikum: Vorlesung 4 60

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.

Grundlagen des Software Engineerings

Ähnliche Präsentationen

Präsentation zum Thema: "Grundlagen des Software Engineerings"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Grundlagen des Software Engineerings

Ähnliche Präsentationen

Präsentation zum Thema: "Grundlagen des Software Engineerings"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback