Grundlagen des software engineerings
This presentation is the property of its rightful owner.
Sponsored Links
1 / 65

Grundlagen des Software Engineerings PowerPoint PPT Presentation


  • 52 Views
  • Uploaded on
  • Presentation posted in: General

Grundlagen des Software Engineerings. Angebotserstellung Modellbasierte Softwareentwicklung Musterbasierte Softwareentwicklung Reverse Engineering. Zur Information. Webseite ist aktualisiert Lastenheft, Vorlesungsfolien, Vorlagen, ... sind online

Download Presentation

Grundlagen des Software Engineerings

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Grundlagen des software engineerings

Grundlagen des Software Engineerings

Angebotserstellung

Modellbasierte Softwareentwicklung

Musterbasierte Softwareentwicklung

Reverse Engineering


Zur information

Zur Information

  • Webseite ist aktualisiert

    • Lastenheft, Vorlesungsfolien, Vorlagen, ... sind online

  • Alle sollten sich auf das erste Meeting vorbereiten, in dem sie / er das Lastenheft gründlich durcharbeitet

  • Kaola-Gruppe ist offen

    • Passwort kam via Mail

Software(technik)praktikum: Vorlesung 1


Swtpra gruppenverteilung

SWTPra-Gruppenverteilung

  • Paul: 77 Teilnehmer

  • Moreganize: 7 Gruppen á 11 Stud., 70 Abstimmungen

  • Problem: Gruppe 7 zu wenig Studenten

    • Lösung 1: Von andere Gruppen abziehen

    • Lösung 2: Gruppe 7 auflösen und auf andere Gruppen verteilen  6 Gruppen mit 11 bzw. 12 Teilnehmern

Neu

Kann sich noch ändern.

Software(technik)praktikum: Vorlesung 1


Swtpra gruppenverteilung1

SWTPra-Gruppenverteilung

  • Paul: 30 Teilnehmer

  • Moreganize: 3 Gruppen á 10 Stud., 29 Abstimmungen

Software(technik)praktikum: Vorlesung 1


Praxis tutorials

Praxis-Tutorials

  • Feedback der Tutoren

    • Tutorials sind effektiver, wenn sie direkt innerhalb der Gruppe aufbereitet und durchgeführt werden

    • Dies war die letzten beiden Jahre sehr erfolgreich.

  • Fazit:

    • Es wird keine gruppenübergreifenden Tutorials geben

    • Bestimmen Sie innerhalb des Teams je Tutorial eine Person, die das Tutorial aufbereitet und mit der Gruppe durchführt

    • Für folgende Themen stellen wir Folien auf der Webseite bereit

      • Eclipse, SVN, Testen, Latex, GEF (GEF nur elevant für SWTPra)

    • Folgende Tutorial sind zusätzlich sinnvoll

      • Trac, EMF + OCL (vor allem SWTPra), Graphiti(relevant für SWTPra als Alternative zu GEF)

    • Sie können selbst entscheiden, welche Tutorials sie durchführen.

Software(technik)praktikum: Vorlesung 1


Angebotserstellung

Angebotserstellung


Ziel dieser vorlesungseinheit

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

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.

8

Software(technik)praktikum: Vorlesung 4


Lastenheft grobes pflichtenheft1

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

9

Software(technik)praktikum: Vorlesung 4


Angebot

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

10

Software(technik)praktikum: Vorlesung 4


Angebot1

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

11

Software(technik)praktikum: Vorlesung 4


Aufwandssch tzung

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

12

Software(technik)praktikum: Vorlesung 4


Aufwandssch tzung1

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.

13

Software(technik)praktikum: Vorlesung 4


Aufwandssch tzung2

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

14

Software(technik)praktikum: Vorlesung 4


Grundlegende sch tzmethoden

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

15

Software(technik)praktikum: Vorlesung 4


Grundlegende sch tzmethoden1

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

16

Software(technik)praktikum: Vorlesung 4


Grundlegende sch tzmethoden2

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)

17

Software(technik)praktikum: Vorlesung 4


Grundlegende sch tzmethoden3

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

Software(technik)praktikum: Vorlesung 4


Beispiel function point methode

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

Function-Point-Methode ist zugeschnitten auf klassische Informationssysteme.

Das Prinzip dahinter lässt sich aber auf andersartige Systeme übertragen.

Software(technik)praktikum: Vorlesung 4


Beispiel function point methode1

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

    • einfacheexterne Eingaben = 3

    • für komplexeinterne 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]

Software(technik)praktikum: Vorlesung 4


Beispiel function point methode2

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.

Software(technik)praktikum: Vorlesung 4


Beispiel function point methode3

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

Software(technik)praktikum: Vorlesung 4


Sch tzverfahren

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

Software(technik)praktikum: Vorlesung 4


Aufwandssch tzung3

Aufwandsschätzung

Positiv-Beispiel:

tabellarisch

ausführlich

mit Std.-Lohn

zusätzlich: beschreibender Text

erledigt

Hauptaufgaben

Teilaufgaben

noch zu tun

Gesamtaufwand

24

Software(technik)praktikum: Vorlesung 4


Aufwandssch tzung4

Aufwandsschätzung

Positiv-Beispiel:

Preis muss nachvollziehbar sein

Auftraggeber hat durch Gliederung die Möglichkeit, einzelne Punkte zu streichen

Teilsummen

25

Software(technik)praktikum: Vorlesung 4


Projektplan

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

    • ...

26

Software(technik)praktikum: Vorlesung 4


Einhaltung des v modells

Einhaltung des V-Modells

Ihr Projektplan soll sich ans V-Modell halten.

Software(technik)praktikum: Vorlesung 4


Projektplan1

Projektplan

  • Verschiedene Darstellungsformen möglich

    • Gantt-Diagramm

    • Aktivitätendiagramm

    • Tabelle

  • Mögliche Werkzeuge

    • Microsoft Project (Erhältlich via MSDNAA)

    • Gantt Project

28

Software(technik)praktikum: Vorlesung 4


Modellbasierte softwareentwicklung

Modellbasierte Softwareentwicklung


Motivation und beispiel

Motivation und Beispiel

  • Was sind „Softwaremodelle“?

  • Wozu sind sie gut?

  • Warum brauchen wir sie?

  • Was ist Software?

  • Was ist ein Modell?

30

Software(technik)praktikum: Vorlesung 4


Modell

Modell

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

31

Software(technik)praktikum: Vorlesung 4


Zweck von modellen

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

32

Software(technik)praktikum: Vorlesung 4


Modell und metamodell

Modell und Metamodell

*

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

33

Software(technik)praktikum: Vorlesung 4


Abstrakte und konkrete syntax

Abstrakte und konkrete Syntax

:Petrinet

source

target

graphische / konkrete Syntax

:Arc

:Place

:Transition

source

target

abstrakte Syntax(in Form eines Objektdiagramms)

:Arc

:Arc

source

target

source

target

:Transition

:Token

:Place

:Arc

34

Software(technik)praktikum: Vorlesung 4


Metamodell und modell

Metamodell und Modell

PetriNet

:Petrinet

*

Element

source

target

:Arc

:Place

:Transition

target

source

1 source

Node

Arc

:Arc

:Arc

1 target

Transition

Place

Token

source

target

target

source

:Transition

:Token

:Place

:Arc

*

Tipp zur Metamodellierung: Erst über die Modellebene nachdenken! Also erst ein Objektdiagramm für ein repräsentatives Beispiel zeichnen und dann ein Klassendiagram erstellen.

Metamodell

ist Instanz von

Modell

konkrete Syntax

abstrakte Syntax

35

Software(technik)praktikum: Vorlesung 4


Klassendiagramm als modell

Klassendiagramm als Modell

PetriNet

*

Element

1 source

Node

Arc

1 target

Transition

Place

Token

*

ClassDiagram

*

*

1 source

Class

Association

1 target

UML-Modell

Ausschnitt des Metamodells der UML (Klassendiagramme)

36

Software(technik)praktikum: Vorlesung 4


Berblick

Überblick

PetriNet

:Petrinet

ClassDiagram

*

Element

source

target

:Arc

:Place

:Transition

:Association

:Class

:Class

:Association

*

*

target

source

1 source

Class

Association

1 source

Node

Arc

1 target

:Arc

:Arc

1 target

Transition

Place

source

Token

target

target

source

:Transition

:Token

:Place

:Arc

*

Modell fürKlassendiagramme

Meta-Meta-Modell

Instanz von

(alternativ: Meta-Modell)

Modell für Petrinetze

Abstrakte Syntax zu

Meta-Modell

(alternativ: Modell)

Instanz von

Abstrakte Syntax zu

Ein Petrinetz

Modell

(alternativ: Instanz)

37

Software(technik)praktikum: Vorlesung 4


Modelle im softwareentwurf

Modelle im Softwareentwurf

  • MOF: Meta-Object Facility (OMG Standard)

beschreibt

Level M3

Meta-Metamodell

MOF

MOF

Instanz von

Instanz von

beschreibt

(UML)

Level M2

Metamodell

UML

Metamodell für Petrinetze

beschreibt

Instanz von

Level M1

Modell

Modell einesDame-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

38

Software(technik)praktikum: Vorlesung 4


Modelle im softwareentwurf1

Modelle im Softwareentwurf

  • 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

Instanz von

beschreibt

(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 einesDame-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

39

Software(technik)praktikum: Vorlesung 4


Modelle im softwareentwurf2

Modelle im Softwareentwurf

  • „Traditionell“: Mehr oder weniger automatisch:

    • Forward-Engineering

    • Reverse-Engineering

    • Re-Engineering

  • Model DrivenArchitecture (MDA)

    • Generierung von (Teilen der)Software aus Modellen

       Modelle sind die Software

40

Software(technik)praktikum: Vorlesung 4


Traditionell

„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

41

Software(technik)praktikum: Vorlesung 4


Traditionell1

„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

42

Software(technik)praktikum: Vorlesung 4


Automatisierung

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

43

Software(technik)praktikum: Vorlesung 4


Musterbasierte softwareentwicklung

Musterbasierte Softwareentwicklung


Bersicht

Übersicht

  • Architekturstile / bzw. Architekturmuster und Entwurfsmuster unterstützen bei der Realisierung von Software

  • Eclipse und insbesondere das GraphicalEditing 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

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 ofReusableObject-oriented Software, Gamma et al., 1995

Bekannt aus der Vorlesung Softwareentwurf

46

Software(technik)praktikum: Vorlesung 4


Erinnerung entwurfsmuster design patterns1

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.

47

Software(technik)praktikum: Vorlesung 4


Erinnerung architekturstile

Erinnerung: Architekturstile

  • Bekannte Architekturstile

    • Schichtenarchitektur

    • Model – View – Controller

    • Web-Service-orientierte Architektur

Bekannt aus der Vorlesung Softwareentwurf


Model view controller

Model-View-Controller

:GraphEditPart

:TransitionEditPart

:PlaceEditPart

:TransitionEditPart

:PlaceEditPart

  • Modelländerung aufgrund Benutzerinteraktion

  • Aktualisierung der Darstellung nach Modelländerung

Controller

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

:Transition

:Token

:Place

:Arc

Model

49

Software(technik)praktikum: Vorlesung 4


Gef nutzt model view controller

GEF nutzt Model-View-Controller

:GraphEditPart

:TransitionEditPart

:PlaceEditPart

:TransitionEditPart

:PlaceEditPart

Controller

In GEF: EditParts

:Petrinet

:Transition

:Arc

:Place

:Arc

:Arc

View

In GEF: Figures

:Transition

:Token

:Place

:Arc

Model

In GEF: EObjects

50

Software(technik)praktikum: Vorlesung 4


Gef nutzt mvc

GEF nutzt MVC

EditParts

EObjects

Figures

Command

2. EditPartViewer erstellt Request

3. erzeugt

Request

4. modifiziert

1. Aktion

6. aktualisiert

5. erzeugtpropertyChangeEreignisse

Editor

Mehr dazu finden Sie in unserem GEF-Tutorial.

51

Software(technik)praktikum: Vorlesung 4


Zusammenfassung

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.


Reverse engineering

Reverse Engineering

53

Software(technik)praktikum: Vorlesung 4


Reverse engineering1

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.

54

Software(technik)praktikum: Vorlesung 4


Szenario im praktikum

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?


    Wartung von software

    Wartung von Software

    • Verstehen von Altsoftware ist sehr kostenintensiv

    [Som12]

    Rebecca Tiarks: WhatMaintenance ProgrammersReally Do: An Observational Study


    Reverse engineering2

    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

    57

    Software(technik)praktikum: Vorlesung 4


    Werkzeuggest tztes reverse engineering

    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

    58

    Software(technik)praktikum: Vorlesung 4


    Vom code zum modell

    Vom Code zum Modell

    publicclass A{ private String name;

    B anAttribute;

    publicvoiddoThis()

    {

    }

    }

    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)

    59

    59

    Software(technik)praktikum: Vorlesung 4


    Beispiel code

    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 booleanhasInShuttles(Shuttle value) {

    ...

    }

    public intsizeOfShuttles() {

    ...

    }

    public void removeAllFromShuttles() {

    ...

    }

    }

    Was von diesem Code ist für das Verständnis relevant?

    60

    Software(technik)praktikum: Vorlesung 4


    Bsp generiertes klassendiagramm

    Bsp.: generiertes Klassendiagramm

    Element

    Track

    - next : Track

    - prev : Track

    «interface»

    Movable

    + getNext() : Track

    + setNext(Track) : void

    + getPrev() : Track

    + setPrev(Track) : void

    Simulation

    + move() : void

    - shuttles: TreeSet

    «implements»

    + 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

    61

    Software(technik)praktikum: Vorlesung 4


    Automatisch generierte diagramme

    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

    62

    Software(technik)praktikum: Vorlesung 4


    Beispiel ergebnis struktur

    Beispiel: Ergebnis (Struktur)

    Element

    «interface»

    Movable

    + move() : void

    «implements»

    0..1

    prev

    0..1

    Shuttle

    Track

    next

    0..*

    0..1

    0..1

    Simulation

    + driving : boolean

    simulation

    shuttles

    at

    + move() : void

    • Manuell nachbearbeitetes Ergebnis:

    63

    Software(technik)praktikum: Vorlesung 4


    Nochmal im vergleich code

    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() {

    ...

    }

    }

    64

    64

    Software(technik)praktikum: Vorlesung 4


    Zusammenfassung1

    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 inhochwertige Dokumente beschrieben sein.


  • Login