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