Grundlagen des Software Engineerings · Software(technik)praktikum: Vorlesung 2 Beispiel:...
Transcript of Grundlagen des Software Engineerings · Software(technik)praktikum: Vorlesung 2 Beispiel:...
• Angebotserstellung • Modellbasierte Softwareentwicklung • Musterbasierte Softwareentwicklung • Reverse Engineering
Grundlagen des Software Engineerings
Angebotserstellung
Software(technik)praktikum: Vorlesung 2
Ziel dieser Vorlesungseinheit
■ Im Praktikum sollen sie zunächst ein Angebot erstellen ■ Angebot setzt sich zusammen aus
■ Aufwandsschätzung ■ Projektplan
■ Angebot wird auf Basis des Lastenheftes verfasst
■ Ziele dieser Vorlesungseinheit ■ Wiederholung zum Lastenheft ■ Lernen, wie eine Aufwandsschätzung erfolgt
■ Schätzverfahren kennen lernen ■ Lernen, wie ein Projektplan erstellt wird
3
Software(technik)praktikum: Vorlesung 2
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
4
Ihr Lastenheft haben Sie bereits von uns erhalten.
Software(technik)praktikum: Vorlesung 2
Lastenheft (grobes Pflichtenheft)
■ Unser Lastenheft ist idealisiert ■ Ausführlich (18 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 2
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 2
Angebot
■ Tipps ■ Darstellung der Aufwände sollte übersichtlich sein
■ z.B. tabellarisch ■ Arbeitspakete und Projektplan als Diagramme visualisieren und textuell beschreiben
■ Keine Diagramme ohne erklärenden Text! ■ Verantwortliche mit Kontaktmöglichkeit angeben ■ Auf Rechtschreibung, Ausdruck, Grammatik achten
7
Software(technik)praktikum: Vorlesung 2
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 2
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
9
Haben Sie nicht.
Haben Sie auch nicht.
Software(technik)praktikum: Vorlesung 2
Aufwandsschätzung
10
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 (Git-Repository) • Vergleich im Abschlussdokument
Software(technik)praktikum: Vorlesung 2
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.
11
Bewertung: + relativ genaue Schätzung - Experten erforderlich
Software(technik)praktikum: Vorlesung 2
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
12
Bewertung: + reale Basis - viel Erfahrung nötig - Mangel an vergleichbaren Projekten - Ähnlichkeit ist subjektiv - Abweichungen schlecht quantifizierbar
Software(technik)praktikum: Vorlesung 2
Grundlegende Schätzmethoden
Multiplikationsmethode ■ Zerlegung des Produkts in Teilprodukte ■ Bewertung anhand vergleichbarer Teilprodukte
13
Bewertung: + vergleichbare Teilprodukte sind eher vorhanden - Bewertung noch nicht in der Planungsphase möglich (Teilprodukte werden
frühestens im Pflichtenheft definiert)
Software(technik)praktikum: Vorlesung 2
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)
14
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 2
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
15Software(technik)praktikum: Vorlesung 2
Function-Point-Methode ist zugeschnitten auf klassische Informationssysteme. Das Prinzip dahinter lässt sich aber auf andersartige Systeme übertragen.
Software(technik)praktikum: Vorlesung 2
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 2
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 2
Beispiel: Function-Point-Methode
■ Über eine Tabelle (mit bisherigen Erfahrungswerten des Unternehmens) werden die Function Points in den Aufwand umgerechnet ■ Hierbei werden dann z.B. auch indirekte Personalkosten berücksichtigt
(z.B. für administratives Personal, für Ausstattung, etc.)
■ Nach Abschluss des Projekts wird die Tabelle aktualisiert
18
Software(technik)praktikum: Vorlesung 2
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
20
Aufwandsschätzung
Positiv-Beispiel: ■ tabellarisch ■ ausführlich ■ mit Std.-Lohn ■ zusätzlich:
beschreibender Text
erledigt
noch zu tun
Teilaufgaben
Gesamtaufwand
Hauptaufgaben
Software(technik)praktikum: Vorlesung 2
21
Positiv-Beispiel:
Preis muss nachvollziehbar sein
Auftraggeber hat durch Gliederung die Möglichkeit, einzelne Punkte zu streichen
Teilsummen
Software(technik)praktikum: Vorlesung 2
Aufwandsschätzung
Software(technik)praktikum: Vorlesung 2
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 2
Einhaltung des V-Modells
23
Ihr Projektplan soll sich ans V-Modell halten.
Software(technik)praktikum: Vorlesung 2
Projektplan
■ Verschiedene Darstellungsformen möglich ■ Gantt-Diagramm ■ Aktivitätendiagramm ■ Tabelle
■ Mögliche Werkzeuge ■ Microsoft Project (Erhältlich via Dreamspark)
■ https://dreamspark.uni-paderborn.de ■ Gantt Project
■ http://www.ganttproject.biz
24
Modellbasierte Softwareentwicklung
Software(technik)praktikum: Vorlesung 2
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 2
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 2
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 2
Modell und Metamodell
29
graphische / konkrete Syntax des Petrinetz-modells
PlaceTransition
1 source
1 targetArc
*
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
29Software(technik)praktikum: Vorlesung 2
Software(technik)praktikum: Vorlesung 2
Abstrakte und konkrete Syntax
30
:Place
:Transition
:Arc
:Transition
:Place
:Arc
:Arc
source
target source
target
targetsource
:Arcsourcetarget
:Petrinet
:Token
graphische / konkrete Syntax
abstrakte Syntax (in Form eines Objektdiagramms)
Software(technik)praktikum: Vorlesung 2
Metamodell und Modell
31
:Place
:Transition
:Arc
:Transition
:Place
:Arc
:Arc
source
target source
target
targetsource
:Arcsourcetarget
:Petrinet
:Token
PlaceTransition
1 source
1 targetArc
*
PetriNet
Token*
Node
Element
Modell
Metamodell
ist Instanz von
konkrete Syntax abstrakte Syntax
Tipp zur Metamodellierung: Erst über die Modellebene nachdenken! Also erst ein Objektdiagramm für ein repräsentatives Beispiel zeichnen und dann ein Klassendiagram erstellen.
Software(technik)praktikum: Vorlesung 2
Klassendiagramm als Modell
32
1 source
1 targetAssociationClass
ClassDiagram
Ausschnitt des Metamodells der UML (Klassendiagramme)
UML-Modell
PlaceTransition
1 source
1 targetArc
*
PetriNet
Token*
Node
Element
**
Überblick
33
:Place
:Transition
:Arc
:Transition
:Place
:Arc
:Arc
source
target source
target
targetsource
:Arcsourcetarget
:Petrinet
:Token
PlaceTransition
1 source
1 targetArc
*
PetriNet
Token*
Node
Element
1 source
1 target
AssociationClass
ClassDiagram
**
:Class:Class
:Association
: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
Instanz von
33Software(technik)praktikum: Vorlesung 2
Software(technik)praktikum: Vorlesung 2
Modelle im Softwareentwurf■ MOF: Meta-Object Facility (OMG Standard)
34
Level M3 Meta-Metamodell
Level M2 Metamodell
Level M1 Modell
Level M0 Instanz/Wirklichkeit
beschreibt
beschreibt
beschreibt Instanz von
Instanz von
Instanz vonInstanz von
beschreibt
MOF
UML
Modell einesDame-Spiels
ein Dame-Spiel (z.B. Brettspiel oder
Simulation im Computer)
MOF
Petri-Netz einer Ampel
eine Ampel (in Wirklichkeit oder
deren Simulation im Computer)
Metamodell für Petrinetze
(UML)
Software(technik)praktikum: Vorlesung 2
Modelle im Softwareentwurf■ MOF: Meta-Object Facility (OMG Standard)
35
Level M3 Meta-Metamodell
Level M2 Metamodell
Level M1 Modell
Level M0 Instanz/Wirklichkeit
beschreibt
beschreibt
beschreibt Instanz von
Instanz von
Instanz vonInstanz von
beschreibt
MOF
UML
Modell einesDame-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…
Software(technik)praktikum: Vorlesung 2
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 2
„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
Software(technik)praktikum: Vorlesung 2
„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.
38
Reverse-Engineering
Re-Engineering = Reverse- & Forward-Engineering
Software(technik)praktikum: Vorlesung 2
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.
39
Roundtrip-Engineering
Musterbasierte Softwareentwicklung
Software(technik)praktikum: Vorlesung 2
Ü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 richtiger 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.
Software(technik)praktikum: Vorlesung 2
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., 1995
42
Bekannt aus der Vorlesung
Softwareentwurf
Software(technik)praktikum: Vorlesung 2
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)
43
Nutzen Sie Entwurfsmuster im
Praktikum!
Software(technik)praktikum: Vorlesung 2
Erinnerung: Architekturstile
■ Bekannte Architekturstile ■ Schichtenarchitektur ■ Model – View – Controller ■ Web-Service-orientierte Architektur
44
Bekannt aus der Vorlesung
Softwareentwurf
Software(technik)praktikum: Vorlesung 2
Model-View-Controller
45
View
Model
:Place
:Transition
:Arc
:Transition
:Place
:Arc
:Arc
:Arc
:Petrinet
:Token
:PlaceEditPart :TransitionEditPart:TransitionEditPart :PlaceEditPart
:GraphEditPart
Controller
Grundidee:Model unabhängig von Controller und View!
Fachmodell (Daten) & Funktionen darauf
Darstellung des Modells & Interaktion mit Benutzer
▪ Modelländerung aufgrund Benutzerinteraktion
▪ Aktualisierung der Darstellung nach Modelländerung
Software(technik)praktikum: Vorlesung 2
GEF nutzt Model-View-Controller
46
In GEF: Figures
In GEF: EObjects
In GEF: EditParts
View
Model
:Place
:Transition
:Arc
:Transition
:Place
:Arc
:Arc
:Arc
:Petrinet
:Token
:PlaceEditPart :TransitionEditPart:TransitionEditPart :PlaceEditPart
:GraphEditPart
Controller
GEF nutzt MVC
47
EObjects Figures
EditParts
2. EditPartViewer erstellt Request
Editor
1. Aktion
Command
3. erzeugt
4. modifiziert
5. erzeugt propertyChangeEreignisse
6. aktualisiert
Software(technik)praktikum: Vorlesung 2
Request
Software(technik)praktikum: Vorlesung 2
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 sie.
48
Reverse Engineering
Software(technik)praktikum: Vorlesung 2
Reverse Engineering
■ Software ... ■ wird heute nicht mehr isoliert eingesetzt ■ muss mit anderer Software interagieren ■ muss oft weiterentwickelt werden 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 2
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?
Smartphone-Beobachter
(SoPra)
Smartphone-Teilnehmer
(SWTPra)
Software(technik)praktikum: Vorlesung 2
Wartung von Software
■ Verstehen von Altsoftware ist sehr kostenintensiv
52[Som12]
Kosten der Software über ihren Lebenszyklus
Ändern
Verstehen
Initialentwicklung
Rebecca Tiarks: What Maintenance Programmers Really Do: An Observational Study
Software(technik)praktikum: Vorlesung 2
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 2
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
55
Vom Code zum Modell
27.01.2016
Apublic 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)
56
Beispiel: Codepublic 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?
Software(technik)praktikum: Vorlesung 2
Bsp.: generiertes Klassendiagramm
57
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»
Software(technik)praktikum: Vorlesung 2
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 2
Beispiel: Ergebnis (Struktur)
■ Manuell nachbearbeitetes Ergebnis:
59
SimulationShuttle+ driving : boolean
+ move() : void
Element«interface» Movable
+ move() : void
«implements»
simulation shuttles
0..1 0..* 0..1
atTrack
prev
next
0..10..1
59
Software(technik)praktikum: Vorlesung 2
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 sollte nicht nur funktionsfähig sein, sondern auch eine erweiterbare Architektur haben, gut dokumentierten Code besitzen und in hochwertigen Dokumenten beschrieben sein.
60
Wir sehen uns wieder morgen um 16:00 (ct).