© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
• Angebotserstellung • Modellbasierte
Softwareentwicklung • Musterbasierte
Softwareentwicklung • Reverse Engineering
Grundlagen des Software Engineerings
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Angebotserstellung
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 3
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
Ihr Lastenheft haben Sie bereits von uns erhalten.
20.04.2015 Software(technik)praktikum: Vorlesung 2 4
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 5
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 6
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 7
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 8
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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.
20.04.2015 Software(technik)praktikum: Vorlesung 2 9
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 10
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 11
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 12
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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)
20.04.2015 Software(technik)praktikum: Vorlesung 2 13
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 14
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
Software(technik)praktikum: Vorlesung 2
Function-Point-Methode ist zugeschnitten auf klassische Informationssysteme. Das Prinzip dahinter lässt sich aber auf andersartige Systeme übertragen.
20.04.2015 Software(technik)praktikum: Vorlesung 2 15
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
[Sommerville, Software Engineering, 1992]
20.04.2015 Software(technik)praktikum: Vorlesung 2 16
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 17
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 18
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 19
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 20 Software(technik)praktikum: Vorlesung 2
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Aufwandsschätzung
20.04.2015 21
Positiv-Beispiel:
Preis muss nachvollziehbar sein Auftraggeber hat durch Gliederung die Möglichkeit, einzelne Punkte zu streichen
Teilsummen
Software(technik)praktikum: Vorlesung 2
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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 ...
20.04.2015 Software(technik)praktikum: Vorlesung 2 22
Do 18.06.15 Do 18.06.15 18.06.
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Einhaltung des V-Modells
Ihr Projektplan soll sich ans V-Modell halten.
20.04.2015 Software(technik)praktikum: Vorlesung 2 23
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 24
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Modellbasierte Softwareentwicklung
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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?
20.04.2015 Software(technik)praktikum: Vorlesung 2 26
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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].
20.04.2015 Software(technik)praktikum: Vorlesung 2 27
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 28
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Modell und Metamodell
graphische / konkrete Syntax des Petrinetz-modells
Place Transition
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 2 20.04.2015 Software(technik)praktikum: Vorlesung 2 29
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Abstrakte und konkrete Syntax
:Place
:Transition
:Arc
:Transition
:Place
:Arc
:Arc
source
target source
target
target source
:Arc source target
:Petrinet
:Token
graphische / konkrete Syntax
abstrakte Syntax (in Form eines Objektdiagramms)
20.04.2015 Software(technik)praktikum: Vorlesung 2 30
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Metamodell und Modell
:Place
:Transition
:Arc
:Transition
:Place
:Arc
:Arc
source
target source
target
target source
:Arc source target
:Petrinet
:Token
Place Transition
1 source
1 target Arc
*
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.
20.04.2015 Software(technik)praktikum: Vorlesung 2 31
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Klassendiagramm als Modell
1 source
1 target Association Class
ClassDiagram
Ausschnitt des Metamodells der UML (Klassendiagramme)
UML-Modell
Place Transition
1 source
1 target Arc
*
PetriNet
Token *
Node
Element
* *
20.04.2015 Software(technik)praktikum: Vorlesung 2 32
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Überblick
:Place
:Transition
:Arc
:Transition
:Place
:Arc
:Arc
source
target source
target
target source
:Arc source target
:Petrinet
:Token
Place Transition
1 source
1 target Arc
*
PetriNet
Token *
Node
Element
1 source
1 target
Association Class
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
33 Software(technik)praktikum: Vorlesung 2 20.04.2015 33
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Modelle im Softwareentwurf
MOF: Meta-Object Facility (OMG Standard)
Level M3 Meta-Metamodell
Level M2 Metamodell
Level M1 Modell
Level M0 Instanz/Wirklichkeit
beschreibt
beschreibt
beschreibt Instanz von
Instanz von
Instanz von Instanz von
beschreibt
MOF
UML
Modell eines Dame-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
20.04.2015 Software(technik)praktikum: Vorlesung 2 34
(UML)
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Modelle im Softwareentwurf
MOF: Meta-Object Facility (OMG Standard)
Level M3 Meta-Metamodell
Level M2 Metamodell
Level M1 Modell
Level M0 Instanz/Wirklichkeit
beschreibt
beschreibt
beschreibt Instanz von
Instanz von
Instanz von 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…
20.04.2015 Software(technik)praktikum: Vorlesung 2 35
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 36
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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!
Forward-Engineering
20.04.2015 Software(technik)praktikum: Vorlesung 2 37
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 38
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 39
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Musterbasierte Softwareentwicklung
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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 richtiger 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.
20.04.2015 Software(technik)praktikum: Vorlesung 2 41
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
Bekannt aus der Vorlesung
Softwareentwurf
20.04.2015 Software(technik)praktikum: Vorlesung 2 42
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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 (?)
Nutzen Sie Entwurfsmuster im
Praktikum!
20.04.2015 Software(technik)praktikum: Vorlesung 2 43
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Erinnerung: Architekturstile
Bekannte Architekturstile Schichtenarchitektur Model – View – Controller Web-Service-orientierte Architektur
Bekannt aus der Vorlesung
Softwareentwurf
20.04.2015 Software(technik)praktikum: Vorlesung 2 44
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 45
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
GEF nutzt Model-View-Controller
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 46
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
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 2
Request
Mehr dazu in unserem Tutorium: Einführung in GEF 20.04.2015 47
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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 sie.
20.04.2015 Software(technik)praktikum: Vorlesung 2 48
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Reverse Engineering
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
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.
20.04.2015 Software(technik)praktikum: Vorlesung 2 50
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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?
Auswahlkriterien?
Smartphone-Beobachter
(SoPra)
Smartphone-Teilnehmer
(SWTPra)
20.04.2015 Software(technik)praktikum: Vorlesung 2 51
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
Wartung von Software
Verstehen von Altsoftware ist sehr kostenintensiv
[Som12]
Initial- entwicklung
Verstehen
Ändern
Wartung
Kosten der Software über ihren Lebenszyklus
Rebecca Tiarks: What Maintenance Programmers Really Do: An Observational Study
20.04.2015 Software(technik)praktikum: Vorlesung 2 52
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 53
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 54
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
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)
20.04.2015 55
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
t Pad
erbo
rn
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?
20.04.2015 56
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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»
20.04.2015 Software(technik)praktikum: Vorlesung 2 57
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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
20.04.2015 Software(technik)praktikum: Vorlesung 2 58
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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..1 0..1
59 20.04.2015 Software(technik)praktikum: Vorlesung 2 59
© F
achg
ebie
t Sof
twar
etec
hnik
, Hei
nz N
ixdo
rf In
stitu
t, U
nive
rsitä
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 sollte nicht nur funktionsfähig sein, sondern
auch eine erweiterbare Architektur haben, gut dokumentierten Code besitzen und in hochwertigen Dokumenten beschrieben sein.
20.04.2015 Software(technik)praktikum: Vorlesung 2 60
