Embed Size (px)
Citation preview
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
• Angebotserstellung• Modellbasierte
Softwareentwicklung• Musterbasierte
Softwareentwicklung• Reverse Engineering
Grundlagen des Software Engineerings
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Angebotserstellung
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
4Software(technik)praktikum: Vorlesung 4
Ihr Lastenheft haben Sie bereits von uns erhalten.
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
5Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
6Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
7Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
8Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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.
9Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
10Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
11Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Grundlegende Schätzmethoden
AnalogiemethodeSchä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
12Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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)
13Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
14Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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 4
Function-Point-Methode ist zugeschnitten auf klassische Informationssysteme.Das Prinzip dahinter lässt sich aber auf andersartige Systeme übertragen.
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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.
17Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
18Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
19Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Aufwandsschätzung
Positiv-Beispiel: tabellarisch ausführlich mit Std.-Lohn zusätzlich:
beschreibender Text
erledigt
noch zu tun
Teilaufgaben
Gesamtaufwand
Hauptaufgaben
20Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Aufwandsschätzung
Positiv-Beispiel:
Preis muss nachvollziehbar sein Auftraggeber hat durch Gliederung die Möglichkeit, einzelne Punkte zu streichen
Teilsummen
21Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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 ...
22Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Einhaltung des V-Modells
23
Ihr Projektplan soll sich ans V-Modell halten.
Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Projektplan
Verschiedene Darstellungsformen möglich Gantt-Diagramm Aktivitätendiagramm Tabelle
Mögliche Werkzeuge Microsoft Project (Erhältlich via MSDNAA) Gantt Project
24Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Modellbasierte Softwareentwicklung
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Motivation und Beispiel
Was sind „Softwaremodelle“? Wozu sind sie gut? Warum brauchen wir sie?
Was ist Software? Was ist ein Modell?
26Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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].
27Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
28Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Modell und Metamodell
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 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Abstrakte und konkrete Syntax
:Place
:Transition
:Arc
:Transition
:Place
:Arc
:Arc
source
target source
target
targetsource
:Arcsourcetarget
:Petrinet
:Token
graphische / konkrete Syntax
abstrakte Syntax(in Form eines Objektdiagramms)
30Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Metamodell und Modell
:Place
:Transition
:Arc
:Transition
:Place
:Arc
:Arc
source
target source
target
targetsource
:Arcsourcetarget
:Petrinet
:Token
PlaceTransition
1 source
1 target
Arc
*
PetriNet
Token*
Node
Element
Modell
Metamodell
ist Instanz von
konkrete Syntax
abstrakte Syntax
31Software(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.
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Klassendiagramm als Modell
1 source
1 targetAssociationClass
ClassDiagram
Ausschnitt des Metamodells der UML (Klassendiagramme)
UML-Modell
PlaceTransition
1 source
1 target
Arc
*
PetriNet
Token*
Node
Element
**
32Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Überblick
:Place
:Transition
:Arc
:Transition
:Place
:Arc
:Arc
source
target source
target
targetsource
:Arcsourcetarget
:Petrinet
:Token
PlaceTransition
1 source
1 target
Arc
*
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ürKlassendiagramme
Modell
Meta-Modell
Meta-Meta-Modell
(alternativ: Instanz)
(alternativ: Modell)
(alternativ: Meta-Modell)
Instanz von
Instanz von
33Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Modelle im Softwareentwurf
MOF: Meta-Object Facility (OMG Standard)
Level M3Meta-Metamodell
Level M2Metamodell
Level M1Modell
Level M0Instanz/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
34Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Modelle im Softwareentwurf
MOF: Meta-Object Facility (OMG Standard)
Level M3Meta-Metamodell
Level M2Metamodell
Level M1Modell
Level M0Instanz/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…
35Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
36Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
„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
37Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
„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
38Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
39Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Musterbasierte Softwareentwicklung
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Ü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 GEF41
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.
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
42Software(technik)praktikum: Vorlesung 4
Bekannt aus der Vorlesung
Softwareentwurf
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
43Software(technik)praktikum: Vorlesung 4
Nutzen Sie Entwurfsmuster im
Praktikum!
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Erinnerung: Architekturstile
Bekannte Architekturstile Schichtenarchitektur Model – View – Controller Web-Service-orientierte Architektur
44
Bekannt aus der Vorlesung
Softwareentwurf
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Model-View-Controller
View
Model
:Place
:Transition
:Arc
:Transition
:Place
:Arc
:Arc
:Arc
:Petrinet
:Token
:PlaceEditPart :TransitionEditPart:TransitionEditPart :PlaceEditPart
:GraphEditPart
Controller
45Software(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
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
GEF nutzt Model-View-Controller
In GEF: FiguresIn GEF: EObjects
In GEF: EditParts
View
Model
:Place
:Transition
:Arc
:Transition
:Place
:Arc
:Arc
:Arc
:Petrinet
:Token
:PlaceEditPart :TransitionEditPart:TransitionEditPart :PlaceEditPart
:GraphEditPart
Controller
46Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
GEF nutzt MVC
EObjects Figures
EditParts
2. EditPartViewer erstellt Request
Editor
1. Aktion
Command
3. erzeugt
4. modifiziert
5. erzeugt propertyChangeEreignisse
6. aktualisiert
47Software(technik)praktikum: Vorlesung 4
Request
Mehr dazu in unserem Tutorium: Einführung in GEF
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Reverse Engineering
49Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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.
50Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
Smartphone- Beobachter
SoPra
Smartphone-Spieler
SWTPra
Auswahlkriterien?
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Wartung von Software
Verstehen von Altsoftware ist sehr kostenintensiv
52
[Som12]
Initialentwicklung
Verstehen
Ändern
Kosten der Software über ihren Lebenszyklus
Rebecca Tiarks: What Maintenance Programmers Really Do: An Observational Study
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
53Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
54Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
5555
Vom Code zum Modell
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)
55Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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?
56Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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»
57Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
58Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
Beispiel: Ergebnis (Struktur)
Manuell nachbearbeitetes Ergebnis:
Simulation
Shuttle
+ driving : boolean
+ move() : void
Element
«interface»Movable
+ move() : void
«implements»
simulation shuttles
0..1 0..* 0..1
at
Track
prev
next
0..10..1
59Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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() { ... }}
60Software(technik)praktikum: Vorlesung 4
© F
achg
ebie
t S
oftw
aret
echn
ik,
Hei
nz N
ixdo
rf I
nstit
ut,
Uni
vers
ität
Pad
erbo
rn
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
Smartphone- Beobachter
SoPra
Smartphone-Spieler
SWTPra
