Grundlagen des Software Engineerings · Software(technik)praktikum: Vorlesung 2 Beispiel:...

transcript

• Angebotserstellung • Modellbasierte Softwareentwicklung • Musterbasierte Softwareentwicklung • Reverse Engineering

Grundlagen des Software Engineerings

Angebotserstellung

Software(technik)praktikum: Vorlesung 2

Ziel dieser Vorlesungseinheit

■ Im Praktikum sollen sie zunächst ein Angebot erstellen ■ Angebot setzt sich zusammen aus

■ Aufwandsschätzung ■ Projektplan

■ Angebot wird auf Basis des Lastenheftes verfasst

■ Ziele dieser Vorlesungseinheit ■ Wiederholung zum Lastenheft ■ Lernen, wie eine Aufwandsschätzung erfolgt

■ Schätzverfahren kennen lernen ■ Lernen, wie ein Projektplan erstellt wird

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.

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

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

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

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

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.

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 (Git-Repository) • Vergleich im Abschlussdokument

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.

Bewertung: + relativ genaue Schätzung - Experten erforderlich

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

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)

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

Beispiel: Function-Point-Methode

■ Standardisiert in der ISO/IEC 20926

■ Zerlegung des Systems in elementare, in sich abgeschlossene Funktionen aus Anwendersicht, z.B. ■ Erfassung einer Adresse ■ Berechnung eines Tarifs ■ Laden/Speichern

■ Function-Point-Bewertung ist unabhängig von der Technologie der Anwendung

15Software(technik)praktikum: Vorlesung 2

Function-Point-Methode ist zugeschnitten auf klassische Informationssysteme. Das Prinzip dahinter lässt sich aber auf andersartige Systeme übertragen.

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

■ 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

■ Über eine Tabelle (mit bisherigen Erfahrungswerten des Unternehmens) werden die Function Points in den Aufwand umgerechnet ■ Hierbei werden dann z.B. auch indirekte Personalkosten berücksichtigt

(z.B. für administratives Personal, für Ausstattung, etc.)

■ Nach Abschluss des Projekts wird die Tabelle aktualisiert

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

Aufwandsschätzung

Positiv-Beispiel: ■ tabellarisch ■ ausführlich ■ mit Std.-Lohn ■ zusätzlich:

beschreibender Text

erledigt

noch zu tun

Teilaufgaben

Gesamtaufwand

Hauptaufgaben

Positiv-Beispiel:

Preis muss nachvollziehbar sein

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

Teilsummen

Aufwandsschätzung

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

Einhaltung des V-Modells

Ihr Projektplan soll sich ans V-Modell halten.

Projektplan

■ Verschiedene Darstellungsformen möglich ■ Gantt-Diagramm ■ Aktivitätendiagramm ■ Tabelle

■ Mögliche Werkzeuge ■ Microsoft Project (Erhältlich via Dreamspark)

■ https://dreamspark.uni-paderborn.de ■ Gantt Project

■ http://www.ganttproject.biz

Modellbasierte Softwareentwicklung

Motivation und Beispiel

■ Was sind „Softwaremodelle“? ■ Wozu sind sie gut? ■ Warum brauchen wir sie?

■ Was ist Software? ■ Was ist ein Modell?

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

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

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*

Element

Abstrakte Syntax des Metamodells für Petrinetze

Abstrakte und konkrete Syntax

:Place

:Transition

:Place

source

target source

target

targetsource

:Arcsourcetarget

:Petrinet

:Token

graphische / konkrete Syntax

abstrakte Syntax (in Form eines Objektdiagramms)

Metamodell und Modell

:Place

:Transition

:Place

source

target source

target

targetsource

:Arcsourcetarget

:Petrinet

:Token

PlaceTransition

1 source

1 targetArc

PetriNet

Token*

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.

Klassendiagramm als Modell

1 source

1 targetAssociationClass

ClassDiagram

Ausschnitt des Metamodells der UML (Klassendiagramme)

UML-Modell

PlaceTransition

1 source

1 targetArc

PetriNet

Token*

Element

Überblick

:Place

:Transition

:Place

source

target source

target

targetsource

:Arcsourcetarget

:Petrinet

:Token

PlaceTransition

1 source

1 targetArc

PetriNet

Token*

Element

1 source

1 target

AssociationClass

ClassDiagram

:Class:Class

: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

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 Instanz von

Instanz von

Instanz vonInstanz von

beschreibt

Modell einesDame-Spiels

ein Dame-Spiel (z.B. Brettspiel oder

Simulation im Computer)

Petri-Netz einer Ampel

eine Ampel (in Wirklichkeit oder

deren Simulation im Computer)

Metamodell für Petrinetze

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 Instanz von

Instanz von

Instanz vonInstanz von

beschreibt

Modell einesDame-Spiels

ein Dame-Spiel (z.B. Brettspiel oder

Simulation im Computer)

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…

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

„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

„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

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

Musterbasierte Softwareentwicklung

Übersicht

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

■ Eclipse und insbesondere das Graphical Editing Framework (GEF) nutzen diese und leiten zu deren 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.

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

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)

Nutzen Sie Entwurfsmuster im

Praktikum!

Erinnerung: Architekturstile

■ Bekannte Architekturstile ■ Schichtenarchitektur ■ Model – View – Controller ■ Web-Service-orientierte Architektur

Bekannt aus der Vorlesung

Softwareentwurf

Model-View-Controller

:Place

:Transition

:Place

:Petrinet

:Token

:PlaceEditPart :TransitionEditPart:TransitionEditPart :PlaceEditPart

:GraphEditPart

Controller

Grundidee:Model unabhängig von Controller und View!

Fachmodell (Daten) & Funktionen darauf

Darstellung des Modells & Interaktion mit Benutzer

▪ Modelländerung aufgrund Benutzerinteraktion

▪ Aktualisierung der Darstellung nach Modelländerung

GEF nutzt Model-View-Controller

In GEF: Figures

In GEF: EObjects

In GEF: EditParts

:Place

:Transition

:Place

:Petrinet

:Token

:PlaceEditPart :TransitionEditPart:TransitionEditPart :PlaceEditPart

:GraphEditPart

Controller

GEF nutzt MVC

EObjects Figures

EditParts

2. EditPartViewer erstellt Request

Editor

1. Aktion

Command

3. erzeugt

4. modifiziert

5. erzeugt propertyChangeEreignisse

6. aktualisiert

Request

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.

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.

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)

Wartung von Software

■ Verstehen von Altsoftware ist sehr kostenintensiv

52[Som12]

Kosten der Software über ihren Lebenszyklus

Ändern

Verstehen

Initialentwicklung

Rebecca Tiarks: What Maintenance Programmers Really Do: An Observational Study

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

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

Vom Code zum Modell

27.01.2016

Apublic class A { private String name; B anAttribute; …

public void doThis() { … } }

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

Beispiel: Codepublic class Shuttle extends Element implements Moveable { private boolean driving; private Track at; private Simulation simulation; public Track getAt() { return this.at; } public void setAt(Track value) { if ((this.at == null && value != null) || (this.at != null && !this.at.equals(value))) { this.at = value; } } public boolean isDriving() { return this.driving; } public void setDriving(boolean value) { this.driving = value; } public Simulation getSimulation() { return this.simulation; } public void setSimulation(Simulation value) { if (this.simulation != value) { if (this.simulation != null) { Simulation oldValue = this.simulation; this.simulation = null; oldValue.removeFromShuttles (this); } this.simulation = value; if (value != null) { value.addToShuttles (this); } } } public void move() { ... } }

public class Simulation { private TreeSet shuttles = new TreeSet(); public void addToShuttles(Shuttle value) { if (value != null) { boolean changed = this.shuttles.add (value); if (changed) { value.setSimulation (this); } } } public Iterator iteratorOfShuttles() { return this.shuttles.iterator (); } public void removeFromShuttles(Shuttle value) { if (value != null) { boolean changed = this.shuttles.remove (value); if (changed) { value.setSimulation (null); } } } public boolean hasInShuttles(Shuttle value) { ... } public int sizeOfShuttles() { ... } public void removeAllFromShuttles() { ... } }

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

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»

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

Beispiel: Ergebnis (Struktur)

■ Manuell nachbearbeitetes Ergebnis:

SimulationShuttle+ driving : boolean

+ move() : void

Element«interface» Movable

+ move() : void

«implements»

simulation shuttles

0..1 0..* 0..1

atTrack

0..10..1

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.

Wir sehen uns wieder morgen um 16:00 (ct).

Grundlagen des Software Engineerings · Software(technik)praktikum: Vorlesung 2 Beispiel:...

Documents