Prozess-Modelle

• Modelle– Wasserfallmodell– V-Modell– Prototypenmodell– Evolutionäres/inkrementelles Modell– Objektorientiertes Modell– Nebenläufiges Modell– Spiralmodell

• Einführung in UML– Klassendiagramme– Anwendungsfalldiagramme

2

Einführung

• Prozess-Modelle legen den organisatorischen Rahmen einer Software-Entwicklung fest

• Prozess-Modelle legen folgendes fest:– Reihenfolge des Arbeitsablaufs (Entwicklungsstufen, Phasenkonzepte) – Durchzuführende Aktivitäten– Definition der Teilprodukte (einschließlich Layout und Inhalt)– Fertigungskriterien (Wann ist ein Teilprodukt fertiggestellt)– Notwendige Mitarbeiterqualifikation– Einzuhaltende Standards, Richtlinien und Werkzeuge

3

Prozess-Modelle

• Wasserfallmodell• V-Modell• Prototypenmodell• Evolutionäre/inkrementelle Modell• Objektorientierte Modell• Nebenläufige Modell• Spiralmodell

4

Das Wasserfall-Modell (1)System-

Anforderungen

Software-Anforderungen

Analyse

Entwurf

Codierung

Testen

Betrieb

5

Das Wasserfall-Modell (2)

• Jede Aktivität ist in der richtigen Reihenfolge und in voller Breite durchzuführen

• Am Ende jeder Aktivität steht ein fertiggestelltes Dokument (Dokumentengetriebenes Modell)

• Sequentielle Abfolge der Aktivitäten (Keine Überlappung von Aktivitäten)

• Iterationen sind nur zwischen zwei aufeinanderfolgenden Stufen erlaubt

6

Das Wasserfall-Modell: Bewertung

Vorteile• Einfach, verständlich• Geringer Management-Aufwand• Disziplinierter, kontrollierbarer und sichtbarer Prozessablauf

Nachteile• Die Sequentialität und volle Breite der Entwicklungsschritte

oft nicht sinnvoll • Gefahr einer Überbewertung der Dokumentation• Risiken werden zu wenig berücksichtigt• Benutzerbeteiligung nur bei Anforderungen und im Betrieb • Möglichkeit von Feedback kaum gegeben

7

Das V-Modell (1)

Anforderungs-Definition

Validierung

AbnahmetestAnwendungsszenarien

Integrationstest

Modul-Implementation

Systemtest

Feinentwurf

TestfälleGrobentwurf

Verifikation

Testfälle

TestfälleModultest

8

Das V-Modell (2)

• Erweiterung des Wasserfall-Modells• Berücksichtigung der Qualitätssicherung

– Verifikation: Überprüfung der Übereinstimmung zwischen Software-Produkt und Spezifikation

– Validierung: Überprüfung der Eignung eines Produktes bezogen auf Einsatzzweck

• Submodelle im V-Modell:– PM: Projektmanagement– SE: Systemerstellung– QS: Qualitätssicherung– KM: Konfigurationsmanagement

9

Das V-Modell: Submodelle

Konfigurations-struktur

PM

SE

QS KM

Plandaten Istdaten SEU

SEU

QS-Ergebnis

Ist-daten

QS-Anforderung

Produkt

Produktentwickeln

QS-Anforderungen

vorgeben

Produkteprüfen

Produkte/Rechte

verwalten

Produktstrukturplanen

Plan-daten SEU SEUPlan-

datenPlan-daten

Ist-daten

Produkt

Rechte

Ist-daten

Voraussetzungen schaffen und SEU bereitstellen

Projekt planen und kontrollieren

10

Das V-Modell: Rollen

Manager Verantwortliche DurchführendeSubmodell

PM Projektmanager ProjektleiterRechtsverantwortlicherController

Projektadministrator

SE ProjektmanagerIT-BeauftragterAnwender

Projektleiter SystemanalytikerSystemdesignerSW-EntwicklerHW-EntwicklerTechnischer AutorSEU-BetreuerDatenadministratorIT-SicherheitsbeauftragterDatenschutzbeauftragterSystembetreuer

QS Q-Manager QS-Verantwortlicher Prüfer

KM KM-Manager KM-Verantwortlicher KM-Administrator

11

Das V-Modell: Bewertung

Vorteile• Integrierte, detaillierte Darstellung von SE, QS, KM und PM• Generisches Vorgehensmodell mit definierten Möglichkeiten

zur Anpassung an projektspezifischen Anforderungen• Gut geeignet für große ProjekteNachteile• Die Vorgehenskonzepte, die für große Projekte geeignet sind

werden unreflektiert auf andere Projekte übertragen• Für kleine und mittlere Softwareentwicklungen führt das V-

Modell zu einer unnötigen Bürokratie• Die im V-Modell definierten Rollen (bis zu 25) sind für

gängige Softwareentwicklungen nicht realistisch • Ohne geeignete Werkzeug-Unterstützung ist das V-Modell

nicht handhabbar

12

Das Prototypen-Modell

Probleme bei der Verwendung des Wasserfall- und V-Modells• Auftraggeber und Endbenutzer können ihre Anforderungen an ein

Software-Produkt oft nicht explizit und vollständig formulieren• In der Entwicklungsphase ist ein Austausch zwischen Anwendern und

Software-Entwicklern notwendig• Für manche Anforderungen gibt es unterschiedliche Lösungen, die mit

dem Auftraggeber diskutiert werden müssen• Die Realisierbarkeit mancher Anforderungen kann theoretisch nicht

garantiert werden und muss durch Experimente ermittelt werden• Für die Projektakquisition muss der (potentielle) Auftraggeber von der

Software-Lösung überzeugt werdenLösung: Prototypen-Modell• Prototypen dienen dazu, relevante Anforderungen oder

Entwicklungsprobleme zu klären• Prototypen stellen Diskussionsbasis dar und helfen bei der

Entscheidungsfindung• Prototypen dienen dazu, Experimente durchzuführen und damit erste

Erfahrungen mit der Anwendung zu sammeln

13

Das Prototypen-Modell

• Prototyping– Unterstützt die frühzeitige Erstellung ablauffähiger Modelle (Prototypen) des

zukünftigen Systems– Dient zur Ermittlung der Realisierbarkeit von Anforderungen

• Arten von Prototypen– Demonstrationsprototyp:

• Stellt ein mögliches Aussehen einer geplanten Software-Lösung dar• Dient zur Auftragsakquisition(Wird i.A. nach Erfüllung der Aufgabe weggeworfen)

– Prototyp im engeren Sinne: • Realisiert Teile der Funktionalität (z.B. Benutzerschnittstelle)• Dient zur Analyse des Anwendungsbereichs

– Labormuster: • Demonstriert technische Umsetzbarkeit der Anforderungen• Dient zur Beantwortung konstruktionsbezogener Fragen und Alternativen

– Pilotsystem: • Ist Kern des Produktes• Wird in Zyklen zum Endprodukt weiterentwickelt

14

Das Prototypen-Modell: horizontale vs. Vertikale Prototypen

HorinzontalePrototypen

Benutzeroberfläche

Anwendung

Systemsoftware

Netzanbindung Datenhaltung

Vertikale Prototypen

Horizontale Prototypen: Realisierung spezifischer Ebenen des SystemsVertikale Prototypen: Realisierung ausgewählter Teile des Zielsystems durch alle Ebenen hindurch

15

Das Prototypen-Modell: Bewertung

Vorteile• Reduzierung von Entwicklungsrisiken durch frühzeitige

Verwendung von Prototypen• Verbesserung der Planung von Software-Entwicklungen• Starke Rückkopplung mit dem Endbenutzer bzw.

Auftraggeber• Förderung der Kreativität bei der Ermittlung von Alternativen

für die ProblemlösungNachteile• Aufwand für die Entwicklung von Prototypen• Aufwand für Prototypentwicklung oft vertraglich schwer zu

fassen• Gefahr der Weiterverwendung von (Wegwerf-)Prototypen

16

Das evolutionäre Modell

Wünsche

Definieren Version X

EinsetzenVersion X

Implement. Version X

Entwerfen Version X

PartiellesModell

Produkt Version X

partielle Architektur

Nullversion X:=0

X:=X+1

Änderungen

Änderungen

17

Das evolutionäre Modell

• Kern bzw. Mussanforderungen des Auftraggebers definieren Produktkern

• Produktkern wird als erstes entworfen und entwickelt (Nullversion)

• Erfahrungen mit Nullversion führen zu neuen Anforderungen aus denen eine neue Version entwickelt wird

• Merkmale des evolutionären Modells– Stufenweise Entwicklung des Produkts, gesteuert durch Erfahrung

von Endbenutzern– Gut geeignet, wenn der Auftraggeber seine Anforderungen noch nicht

vollständig überblickt– Die Entwicklung im evolutionären Modell ist Code-

getrieben: Der Fokus liegt jeweils auf lauffähigen Teilprodukten

18

Das evolutionäre Modell: Bewertung

Vorteile• Einsatzfähige Produkte in kurzen Zeitabständen• Lässt sich mit dem Prototypen-Modell kombinieren• Auswirkungen des Produkteinsatzes lassen sich untersuchen

und die gewonnene Erfahrungen werden in der folgenden Version berücksichtigt

• Die Richtung der Entwicklung ist leichter steuerbar: statt einem Ergebnis gibt es mehrere Zwischenergebnisse

Nachteile• Falls in der Nullversion Kernanforderungen übersehen

wurden muss die Systemarchitektur u.U. vollständig überarbeitet werden

• Die Nullversion kann sich als zu unflexibel für spätere Anpassungen erweisen

19

Das Inkrementelle Modell

Definieren

EntwerfenVersion X

EinsatzVersion X

Implement.Version X

DefinierenÄnderungen

Wünsche

Änderungen

modifiz.ModellÄnderungen

Änderungen

VollständigesProduktmodell

ProduktVersion X

partielle Architektur

If X>0

X:=X+1Nullversion

X:=0If X=0

Variation des evolutionären Modells:– Die Anforderungen werden zunächst vollständig erfasst– Teile der Anforderungen werden inkrementell umgesetztZiel: Sicherstellen, dass inkrementelle Entwicklungen zu bisherigen Zwischenergebnissen passen

20

Das nebenläufige ModellDefinieren Kernsystem

partiellesModell Definieren

Ausbaustufe 1

DefinierenAusbaustufe 2

Implement. Kernsystem

Änderungen

EntwerfenKernsystem

erweitertesModell

ImplementierenAusbaustufe 1

EntwerfenAusbaustufe 2

ImplementierenAusbaustufe 2

EntwerfenAusbaustufe 1

Änderungen

ErweitertesProduktmodell

ÄnderungenErw. Produkt-

architektur ...

erweitertesKernsystem

erweiterteArchitektur

Änderungen

Kernsystem

partielleArchitektur

...

Produkt

...erweitertesProdukt

21

Das Nebenläufiges Modell

• Parallelisierung des sequentiell organisierten Entwicklungsprozesses

• Förderung der Zusammenarbeit der einzelnen Personengruppen– Dadurch Reduzierung unnötiger Korrekturen– Erfahrungen der unterschiedlichen Personengruppen werden

frühzeitig berücksichtigt

• Reduzierung von Wartezeiten und Zeitverzögerungen durch– Parallelisierung– Minimierung des Ausprobierens (Motto: „right the first time“: richtige

Entscheidungen von Anfang an!)– Reduzierung der Wartezeiten zwischen organisatorisch verbundenen

Aktivitäten

22

Das Nebenläufiges Modell: Bewertung

Vorteile• Frühzeitige Erkennung und Lösung von Problemen• Optimale ZeitausnutzungNachteile• Frühzeitige Entscheidungen können falsch sein• Grundlegende und kritische Entscheidungen werden zu spät

getroffen: Dadurch werden Iterationen notwendig• Hoher Planungs- und Personalaufwand, um Fehler zu

vermeiden bzw. zu antizipieren

23

Das Spiralmodell

24

Das Spiralmodell: Schritte (1)

Schritt 1• Identifikation der Ziele des Teilprodukts (Leistung,

Funktionalität, ...)• Ermittlung alternativer Realisierungsmöglichkeiten (Entwurf

A, Entwurf B, Wiederverwendung, Kauf, etc.)• Ermittlung der Randbedingungen für jede Alternative

(Kosten, Zeit, Schnittstellen usw.)Schritt 2• Evaluierung der Alternativen unter Berücksichtigung der Ziele

und Randbedingungen.• Zeigt die Evaluierung, dass es Risiken gibt, dann ist eine

kosteneffektive Strategie zu entwickeln, um die Risiken zu überwinden (Prototypen, Simulationen, Benutzerbefragungen, etc.)

25

Das Spiralmodell: Schritte (2)

Schritt 3• In Abhängigkeit von den verbleibenden Risiken wird das

Prozessmodell für diesen Schritt festgelegt (z.B. evolutionäres Modell, Prototypenmodell oder Wasserfallmodell)

• Kombination von verschiedenen Modellen ist möglich, wenn dadurch die Risiken minimiert werden

Schritt 4• Planung des nächsten Zyklus einschließlich der benötigten

Ressourcen • Überprüfung (Review) der Schritte 1 bis 3 einschließlich der

Planung für den nächsten Zyklus durch die betroffenen Personengruppen oder Organisationen.

• Einverständnis (Commitment) über den nächsten Zyklus herstellen

26

Das Spiralmodell

• Meta-Modell• Risikogetriebenes Modell, oberstes Ziel: Risikominimierung• Für jedes Teilprodukt und für jede Verfeinerungsebene sind

die vier zyklischen Schritte zu durchlaufen• Ziele eines Zyklus ergeben sich aus den Ergebnissen des

letzten Zyklus • Separate Spiralzyklen können für verschiedene Software-

Komponenten durchgeführt werden• Keine Trennung von Entwicklung und Wartung

27

Das Spiralmodell: Bewertung

Vorteile• Flexibles Modell• Periodische, risikogetriebene Überprüfung und erneute Festlegung des

Ablaufs• Ein Prozessmodell wird nicht für die gesamte Entwicklung festgelegt,

Integration anderer Prozessmodelle• Fehler und ungeeignete Alternativen werden früh eliminiert• Unterstützung der Wiederverwendung durch Betrachtung von

AlternativenNachteile• Hoher Managementaufwand, da oft Entscheidungen über den

Prozessablauf getroffen werden müssen• Für kleine und mittlere Projekte ungeeignet• Wissen über die Handhabung von Risiken nicht immer verfügbar

28

Zusammenfassung

Prozess-Modell

Primäres Ziel AntreibendesMoment

Benutzer-beteiligung

Charakteristika

Wasserfall-Modell

minimaler Manage-mentaufwand

Dokumente gering sequentiell, volleBreite

V-Modell maximale Qualität(safe-to-market)

Dokumente gering sequentiell, volleBreite, Validation,

VerifikationPrototypen-

ModellRisikominimierung Code hoch nur Teilsysteme

Evolutionäres-Modell

minimaleEntwicklungszeit(fast-to-market)

Code mittel nur Kernsystem

Inkremen-telles Modell

minimaleEntwicklungszeit

Risikomimimierung

Code mittel volle Definition,dann zunächst nur

KernsystemNebenläufigesModell

minimaleEntwicklungszeit

Zeit hoch volle Breite,nebenläufig

Spiralmodell Risikominimierung Risiko mittel Entscheidung proZyklus über

weiteres Vorgehen

29

Einführung in UML• UML (Unified Modeling Language) ist eine standardisierte

Sprache und Notation zur Darstellung, Konstruktion, Dokumentation und Spezifikation von (objektorientierten) Modellen

• UML verwendet verschiedene Diagrammtypen zur Darstellung unterschiedlicher Aspekte eines Systems– Statische Aspekte– Dynamische Aspekte– Benutzeranforderungen an das System– Implementierungsbezogene Aspekte

30

Diagrammtypen in UML

• Modellierung der statischen Aspekte– Klassen- und Objektdiagramme: Darstellung von Klassen,

Objekten und deren statischen Beziehungen• Modellierung der dynamischen Aspekte

– Verhaltensdiagramme: Beschreiben das Verhalten von Objekten des Systems

• Sequenzdiagramme: Darstellung von Nachrichtenfolgen zwischen Objekten einer oder mehrerer Klassen

• Kollaborationsdiagramme: Beschreiben das Zusammenwirken von Objekten beim Ausführen von Operationen

• Zustandsdiagramme: Darstellung der Zustände und Zustandsübergänge der Objekte einer Klasse

• Modellierung der funktionalen Anforderungen an das System– Anwendungsfalldiagramme: Darstellung der Interaktionen

zwischen externen Objekten (Akteuren) und dem System• Modellierung implementierungsbezogener Aspekte

(Komponentendiagramme, Einsatzdiagramme)

31

Klassendiagramme

Klassenname

Attribute

Methoden

Attributname: TypAttributname: Typ=Initialwert[+|-|#]Attributname: Typ=InitialwertKlassenattributname: Typ=Initialwert

OperationsnameOperationsname: RückgabetypOperationsname (Parameter: Typ): Rückgabetyp[+|-|#] Operationsname (Parameter: Typ): RückgabetypKlassenoperation (Parameter: Typ): Rückgabetyp

Sichtbarkeit+: public#: protected-: private

Klassenname

32

Klassendiagramme: Beispiele (1)

• Klassen werden durch Rechtecke dargestellt• Klassenname muss eindeutig sein

Person Kunde Firma

GeomObjekt

Position_x : int

verschieben(int, int)

Position_y : int

33

Klassendiagramme: Beispiel

Klassensymbolpublic class GeomObjekt {

int Position_x;int Position_y;public void verschieben (int dx, int dy) {

Position_x = Position_x + dx; Position_y = Position_y + dy;

}}

Java-UmsetzungGeomObjekt

Position_x : int

verschieben(int, int)

Position_y : int

Position_x : 0

Position_y : 0

MeinGeomObjekt:GeomObjekt

Objektsymbol

34

Klassendiagramme: Beziehungen

• Assoziation: Darstellung struktureller Beziehungen• Aggregation: Darstellung hierarchischer Beziehungen• Generalisierung und Spezialisierung

35

Klassendiagramme: Assoziationen

• Strukturelle Beziehungen zwischen Klassen werden durch Assoziationen dargestellt

• Binäre, n-äre und reflexive Assoziationen sind möglich• Zusatzinformationen bei Assoziationen:

– Name der Assoziation: Beschreibt Art der Beziehung (Optional kann die Leserichtung angegeben werden)

– Rollen in der Assoziation: Beschreiben die Rollen der an der Assoziation beteiligten Klassen

– Kardinalität der Assoziation: Gibt an, mit wie vielen Objekten der gegenüberliegenden Klasse ein Objekt assoziiert sein kann

Klasse 1

Klasse 1 Klasse 1Klasse 1 Klasse 1 Klasse 1

Binäre Assoziation Reflexive Assoziation n-äre Assoziation (n=3)

36

Klassendiagramme: Assoziationen

* 1 beschäftigt

Mitarbeiter

Name

......Adresse

LeserichtungUnternehmen

Name

......Adresse

verheiratet mitKatja: Person Bernd: Person

Rollenname

Arbeitsnehmer ArbeitsgeberPerson Unternehmen

37

Klassendiagramme: Aggregation

• Sonderform der Assoziation• Dient zur Darstellung von Teil-ganzes-Beziehungen

1 1..*

besteht ausUnternehmen Abteilung1 1..*

besteht aus Mitarbeiter

besteht ausTeam Teammitglied1..n1

38

Klassendiagramme: Generalisierung und Spezialisierung (1)

• Bei der Generalisierung und Spezialisierung werden Eigenschaften hierarchisch gegliedert, d.h allgemeine Eigenschaften werden Oberklassen und speziellere Eigenschaften Unterklassen zugeordnet

• Unterklassen verfügen über ihre speziellen Eigenschaften und erben die Eigenschaften ihrer Oberklassen

Oberklasse Geschäftspartner

LieferantKundeUnterklase

39

Klassendiagramme: Generalisierung und Spezialisierung (2)

Position_x : intPosition_y : intSichtbar: BooleanAnzeigen()verschieben(int, int): void

Rechtecka : intb : intsetA(neuA)setB(neuB)

Dreiecka : intb : intC: intsetA(neuA)setB(neuB)setC(neuC)

GeomObjekt

KreisRadius: int

SetRadius(int)

40

Anwendungsfalldiagramme (1)

• Ein Anwendungsfalldiagramm besteht aus einer Menge von Anwendungsfällen und stellt Beziehungen zwischen Akteuren und Anwendungsfällen dar

• Anwendungsfälle beschreiben – das für den Benutzer sichtbare Systemverhalten– wie Akteure mit dem System interagieren

• Akteure repräsentieren Rollen (Konkrete Benutzer können gleichzeitig mehrere Rollen spielen)

41

Anwendungsfalldiagramme (2)

UML-Notation

Name Anwendungsfall

<<actor>>Name Akteuroder

Name

Name Beziehung zwischen Anwendungsfall und Akteur: Der Akteur führt den Anwendungsfall aus.

<<actor>>Name

42

Anwendungsfalldiagramme: Beispiel

Auftrag annehmen

Auftrag ausliefern

Bestellung tätigen

Auftrag abbrechen Lieferung

akzeptierenSystemgrenze

<<actor>>Kunde

<<actor>>Lieferant

43

Literatur

• Balzert, H.: Lehrbuch der Software-Technik; Spektrum,Akad. Verl.; Heidelberg, 1996

• Kahlbrandt, B.: Software-Engineering mit der Unified Modeling Language; Springer Verlag, 2001