Präsentation zur Lehrveranstaltung "Software Engineering"

Software Engineering
Studiengang Betriebsinformatik
Sommersemester 2012
Vorlesung : 5 Veranst. á 2 DS
Praktikum : 2 Veranst. á 3 DS
= 20 Unterrichtsstunden
= 12 Unterrichtsstunden
1

Inhalt
1. Einführung: Ziele und Arbeitsmethoden der Softwaretechnologie
2. Objektorientierte Modellierung
Unified Modeling Language (UML 2)
3. Implementation von UML-Modellen
4. Systemarchitekturen
5. Der Software-Entwicklungsprozess
6. Wiederverwendung
2

Literatur
H. Balzert: Lehrbuch der Objektmodellierung. Analyse und Entwurf
mit der UML 2.
Spektrum Akademischer Verlag, 2004
M. Fowler, K. Scott: UML konzentriert. Eine Einführung in die Standard-
Objektmodellierungssprache.
Addison-Wesley, 2. Aufl., 2000
C. Rupp, S. Queins, B. Zengler:
UML 2 glasklar, Praxiswissen für die UML-Modellierung
Carl Hanser Verlag, 3. Aufl., 2007
W. Pree: Komponentenbasierte Softwareentwicklung mit Frameworks.
dpunkt.verlag, 1997
I. Sommerville: Software Engineering.
Addison-Wesley, 8. Aufl. 2007
3

1 Einführung: Ziele und Arbeitsmethoden der
Softwaretechnologie
• Softwareproduktion
• Lebenszyklusmodelle
• Methodologie
→ Objekttechnologie
• von Algorithmen zu Domänen
4

• „Große Systeme“:
Entwicklergruppen über längere Zeit
• Personen (Nutzer) agieren in Rollen
offen für
Fragestellungen
• Entwicklung endet nicht mit der 1. Systemversion:
Erweiterung und Anpassung („Wartung“)
• Wiederverwendung beginnt nicht erst mit der
eigenen Entwicklung
• Bestimmte Entwicklungsmethoden führen zu
bestimmten Software-Architekturen
• Entwicklungsmethoden bedürfen einer
rechentechnischen Unterstützung : CASE
• Zweckbindung -> Musterarchitekturen
5

Phasen im Softwareentwicklungsprozess:
Analyse
Anforderungsanalyse (Pflichtenheft)
Anwendungsfallanalyse
Problembereichsanalyse (Geschäftsklassen)
Entwurf
Softwareentwurf
(Geschäftsklassen + Fachklassen)
Algorithmenentwurf
Komponenten-/Systementwurf
Implementation
Programmierung, weitestgehende Generierung
Test
Unittest, Integrationstest, Systemtest
→ möglichst entwicklungsbegleitend
6

Lebenszyklusmodelle:
7

V-Modell
9

Die Unified Modeling Language
( G. Booch, J. Rumbough, I. Jacobson )
► Diagramme visualisieren Ausschnitte aus bzw. Sichten auf
Modelle
– Diagrammtypen
– Modelltypen
– Eine grafische Sprache
– Metamodellierung
10

Diagrammtypen
Strukturdiagramme
• Klassen-Diagramm (class diagram)
• Objekt-Diagramm (object diagram)
• Paket-Diagramm (package diagram)
• Kompositionsstruktur-Diagramm (composite structure diagram)
• Komponenten-Diagramm (component diagram)
• Verteilungs-Diagramm (deployment diagram)
• Profil-Diagramm (ab UML 2.2) (profile diagram)
Verhaltensdiagramme
• Use-Case-Diagramm (use case diagram)
• Zustands-Diagramm (state machine diagram)
• Aktivitäten-Diagramm (activity diagram)
• Sequenz-Diagramm (sequence diagram)
• Kommunikations-Diagramm (communication diagram)
• Zeitverlaufs-Diagramm (timing diagram)
• Interaktionsübersichts-Diagramm (interaction overview diagram)
11

UML – eine grafische Sprache
Icons:
Grafiken fester Größe und festen Inhalts
2-d Symbole: variable Ausdehnung, beinhalten andere Symbole
Pfade:
Strings:
Constraints:
Folgen von Liniensegmenten, an beiden Enden
mit grafischen Elementen verbunden
mit Syntax, singulär oder anderen Elementen zugeordnet
beschreiben semantische Beziehungen zwischen
Modellelementen
Kommentare:
12

Metamodellierung
► Die UML ist eine grafische formale Sprache
=> Syntax + Semantik
► Die Definition einer formalen Sprache erfolgt mit den Mitteln einer
(formalen) Sprache
=> Metasprache zur Definition einer Objektsprache
Bsp.:
EBNF zur Definition der Syntax von Programmiersprachen
► UML zur Modellierung von UML-Konzepten
=> Metamodelle (Definition der abstrakten Syntax der UML)
13

2 Objektorientierte Modellierung
• Klassen-Instanzen-Abstraktion
• Attribute und Operationen
• Sichtbarkeit und Lebensdauer
• Assoziationen und Verknüpfungen
• Aggregation und Komposition
• Generalisierung und Spezialisierung
• Vererbung und Delegation
• Polymorphie
• Abstrakte und konkrete Klassen
• Instanzen als Laufzeitobjekte
• Statechart-Modelle
• Aktivitäten-Diagramme
14

Klassen-Instanzen-Abstraktion
Objekt
ist ein (abstrakter) Gegenstand oder ein Konzept mit klarer Abgrenzung und
präziser Bedeutung.
Beispiele: Kommissar Rex, das Fenster links oben im Haus, Herr Lutze,
Mediatec GmbH, ein bestimmter Button auf der GUI des Finanzprogrammes,
...
Klasse
umfasst eine Menge von Objekten, die
• ähnliche Struktur und ähnliche Merkmale (Attribute) besitzen,
• ähnliches Verhalten zeigen (Operationen bzw. „Methoden“),
• in Relationen zu Objekten anderer Klassen oder der gleichen Klasse stehen.
Eine Klasse kann durch Aufzählung der Objekte oder durch
die Definition der Eigenschaften der Objekte (Klassendefinition) beschrieben
werden.
Zu einer Klasse gehörige Objekte werden als Instanzen, Instanzobjekte oder
auch Exemplare der Klasse bezeichnet. Klassen werden benannt.
Beispiele: Hund, Fenster, Person, Firma, Button, ...
15

Objekte
• sind immer Instanzen einer bestimmten Klasse und
• besitzen eine Identität und eine Lebensdauer.
Jedes Objekt kennt die Klasse, zu der es gehört.
Die Identifizierung und Benennung von Objekten hilft, die zu modellierende Welt
zu verstehen. Objekte sind Ausgangspunkt für Implementierungen auf
Computern.
Eine Klassendefinition umfasst (evtl. implizit) eine Vorschrift zur Erzeugung von
Instanzen („Konstruktor“).
Klassenbildung ist Abstraktion
( bei einer Abstraktion werden unwesentliche Eigenschaften weggelassen;
sprich: es wird von unwesentlichen Eigenschaften abstrahiert ).
Abstraktion ist ein mächtiges Mittel zur Bewältigung von Komplexität.
Art und Weise der Zerlegung eines Problems bzw. einer Domäne in
Klassen/Objekte ist subjektiv
16

Attribute und Operationen
Attribut :
Merkmal mit einer Ausprägung (Datenwert)
Jedes Attribut besitzt einen Wert aus dem Wertebereich für jedes Objekt.
Jedes Objekt einer Klasse kann für dasselbe Attribut zum selben Zeitpunkt
einen anderen Wert besitzen
-> „Instanzvariable“
Operation : Funktion, die auf Objekte einer Klasse angewendet werden kann.
Alle Objekte einer Klasse haben die gleichen Operationen.
Implementierung der Operation in Programmiersprache -> „Methode“
Beispiel:
Person
name:string
vorname:string
geschlecht:char
geburtsjahr:int
+alter:int
Max:Person
Moritz:Person
17
Mit Topcased erstellt

• Die Gesamtheit der Werte (d.h. der Ausprägungen) aller Attribute
eines Instanzobjektes bestimmt den Zustand des Objekts
zu einem bestimmten Zeitpunkt.
• In Operationen kann auf Werte von Attributen zugegriffen werden. Das
Verhalten eines Objekts wird auch durch seinen Zustand mit bestimmt
(im Unterschied zu einer Prozedur).
• Die Verhaltensbeschreibung existiert unabhängig von der Anzahl vorhandener
Instanzen je Klasse nur einmal und ist der Klasse zugeordnet.
18

Klassendiagramme (eigentlich: Klassenstrukturdiagramme)
formale grafische Notation für die Modellierung von Objekten, Klassen und Relationen,
wird durch Entwicklungswerkzeuge unterstützt.
Klassen
klassenname
[visibility] attributname : datentypname [ = default-wert ]
…
[visibility] operationsname ( argumentliste ) : ergebnistypname
…
19

Instanzen
[ instanzname ] : klassenname
attributname = wert
…
Instanziierungsrelation
klassenname
[instanzname] : klassenname
Klassen- u. Instanzensymbole können bei manchen Werkzeugen innerhalb eines
Klassendiagramms verwendet werden (z.B. Topcased).
20

Person
name:string
vorname:string
geschlecht:char
geburtsjahr:int
+alter:int
Max:Person
Moritz:Person
Unterscheiden:
→ Wert einer Instanzvariablen name
→ Name (Benennung) eines Objekts, z.B. Moritz
21

Sichtbarkeit und Lebensdauer
►
Konstruktoren sind spezielle Operationen zur Erzeugung von Objekten. Objekte
existieren solange, solange sie referenzierbar sind bzw. bis sie explizit aus der
Objektwelt entfernt werden (durch Destruktoren).
► Durch Benennungen werden Objekten Namen (in einer Umgebung) zugeordnet.
► Objekte besitzen einen zeitlich veränderlichen Zustand
-> bestimmt durch die Werte aller Instanzvariablen (Ausprägungen aller Attribute)
► Sichtbarkeit (visibility) für Attribute und Operationen:
+ public von überall sichtbar
# protected nur eigene Klasse und
abgeleitete (spezialisierte) Klassen
- private nur eigene Klasse
~ (oder keine Angabe) package wide nur Klassen innerhalb eines Package
22

Unterscheidung:
instance scope -> „Instanzvariablen“, „Methoden“
class scope -> „Klassenvariablen“, „Klassenmethoden“
(Syntax: Name und Typ werden unterstrichen)
23

Assoziationen und Verknüpfungen
Assoziation:
abstrakte, nicht näher charakterisierte Beziehung zwischen
zwei (binäre A.) oder
mehr (ternäre A. bzw. Assoziation höherer Ordnung) Klassen.
Notation: binäre Ass.: Linie, die zwei Klassensymbole verbindet.
A. höherer Ordn.: Rhombus, der durch Linien mit den
Klassensymbolen verbunden ist.
Beispiel:
24

Verknüpfung: Element einer Assoziation. Setzt eine Anzahl von Objekten
( „Link“ ) in Beziehung
25

Ein Pfad einer Assoziation kann an jedem Ende eine Beschriftung tragen.
Arten der Beschriftung (Auswahl):
Multiplizität
untere_grenze .. obere_grenze
0 .. *
Ordnung
geordnete Elemente werden durch {ordered} spezifiziert
Rollenname
spezifiziert die Rolle, die die Klasse am Ende des Pfades spielt
Aggregationsindikator
hohler/ausgefüllter Rhombus
26

Aggregation und Komposition
Aggregation: bezeichnet die „Teil-Ganzes“-Relation
(„ist Teil von“ bzw. „besteht aus“)
Objekte, die die Komponenten einer Sache repräsentieren, sind mit einem Objekt verknüpft,
das die Komponentengruppe repräsentiert.
Notation:
Ein Objekt der Klasse1 repräsentiert die Komponentengruppe,
Objekte der Klasse2 repräsentieren die Komponenten
28

Eigenschaften:
• Eine Aggregation ist eine Sonderform der Assoziation mit zusätzlicher Semantik
• Einschränkung auf Beziehung zwischen einer Komponentengruppenklasse und
einer Komponentenklasse
(eine Komponentengruppe mit Komponenten verschiedener Typen hat
entsprechend viele Aggregationsrelationen)
• Eine Aggregation ist transitiv und antisymmetrisch
• einige Eigenschaften der Komponentengruppe pflanzen sich auf die Komponenten fort
29

Beispiel: Ein Dokument besteht aus mehreren Absätzen, die ihrerseits aus mehreren
Sätzen bestehen.
Beispiel: In der Programmiersprache C sind ein Name, eine Argumentliste und eine
Verbundanweisung Teile einer Funktionsdefinition.
30

Feststellungen:
Komponentenobjekte können unabhängig vom Komponentengruppenobjekt existieren.
Beispiel: Teile eines Computers
Die Existenz eines Komponentenobjektes kann von der Existenz des
Komponentengruppenobjektes abhängen, zu dem es gehört.
Beispiel: Die Leimung ist Teil eines Buches zu dem sie gehört.
Komposition - bezeichnet eine „enge“ Aggregation.
- konstituiert eine Verbindung der Teile mit dem Ganzen auch
hinsichtlich der „Lebenslinie“.
31

Beispiel:
32

Generalisierung/Spezialisierung und Vererbung
Spezialisierung:
Bezeichnungen
Beziehung zwischen einer Klasse und einer oder mehrerer
verfeinerter (speziellerer) Versionen davon.
Gegenrichtung: Generalisierung
Oberklasse
(Superklasse)
die Klasse, die verfeinert wird
Unterklasse
(Subklasse)
jede Klasse, die eine verfeinerte Version ist
Inklusionsrelation
(„is a“-Relation)
Spezialisierungsbeziehung zwischen Klassen
Eigenschaften: transitiv, antisymmetrisch
33

Vererbung:
• „Merkmale“, die der Oberklasse zugeordnet sind, werden an die Unterklassen
weitergegeben und von den Unterklassen genutzt, sie gelten auch für die
Unterklassen und müssen dort nicht erneut angegeben werden.
entlang der Inklusionsrelation werden „Merkmale“ vererbt.
• Unterklassen können Merkmale spezialisieren, d.h.
– zusätzliche Attribute
– zusätzliche Operationen
– für geerbte Operationen spezielle Realisierungen vorsehen
– Default-Werte für geerbte Attribute neu festlegen
• die Begriffe Vorfahre und Nachkomme beschreiben Generalisierung/Spezialisierung
(und Vererbung) über mehrere Ebenen hinweg
• eine Instanz einer Unterklasse ist gleichzeitig eine Instanz aller ihrer
Vorfahrenklassen
34

Beispiel:
• jedes Buch,
• jedes Fachbuch,
• jedes Informatik-Fachbuch
besitzt einen Autor und eine ISBN
• jedes Fachbuch,
• jedes Informatik-Fachbuch,
• jedes Medizin-Fachbuch
besitzt ein Literaturverzeichnis
35

Constraints:
neben dem Dreieck in geschweiften Klammern notiert.
overlapping, falls ein Nachkomme von mehr als einer Subklasse
abgeleitet werden kann, andernfalls disjoint
complete, falls die Anordnung der Subklassen vollständig ist,
andernfalls incomplete
36

Ein Diskriminator
kennzeichnet eine Partitionierung der Subklassen.
(es wird nach verschiedenen Gesichtspunkten spezialisiert)
-> an die Linie neben dem Dreieck notiert
Mehrfachvererbung:
Klassenhierarchie:
Klassenheterarchie:
eine Klasse kann mehrere Subklassen,
aber nur eine Superklasse besitzen.
eine Klasse kann mehrere Subklassen und
mehrere Superklassen besitzen.
Besitzt eine Klasse mehrere Superklassen, spricht man von Mehrfachvererbung.
Die Klasse erbt Merkmale von allen Superklassen.
Ein Merkmal aus der gleichen Vorfahrenklasse, das in mehr als einem Pfad
gefunden wird, wird nur einmal geerbt.
Es können Mehrdeutigkeiten auftreten.
38

Vererbung und Delegation
Mittels Aggregation + Delegation kann (in der Programmiersprache)
fehlende Mehrfachvererbung umgangen werden.
Delegation: eine Klasse A hat ein Attribut mit Wertebereich Klasse B.
(Instanzen von A besitzen für das Attribut als Wert einen Verweis
auf eine Instanz von B)
= Implementierungsmechanismus, mittels dessen ein Objekt eine
Operation auffängt und an ein Objekt entsprechend der Aggregation
sendet.
Operationen werden aber nicht automatisch über die Aggregation hinweg vererbt!
Beispiel :
40

Beispiel: Realisierungsmöglichkeiten bei fehlender Mehrfachvererbung
41

Polymorphie
• wörtlich: „Vielgestaltigkeit“.
• hier: eine durch Namen und Signatur spezifizierte Operation kann in
unterschiedlichen abgeleiteten Klassen durch unterschiedliche Methoden
implementiert sein.
Signatur: Anzahl und Typen der Parameter einer Operation sowie ggf.
Typ des Rückgabewertes
statische Polymorphie vs. dynamische Polymorphie
gleichnamige Operationen mit
unterschiedlichen Parametertypen
„späte Bindung“
45

Beispiel:
Statische
Polymorphie
Dynamische
Polymorphie
= späte Bindung, dynamische Bindung
46

Beispiel: Baumklassen
47

Rekursive Definition:
Ein Mobile ist
- ein Gewicht oder
- ein Gestänge mit Mobiles an beiden Enden
50

Abstrakte und konkrete Klassen
Abstrakte Klasse:
Klasse, die selbst keine direkten Instanzen besitzt,
deren Nachkommen aber direkte Instanzen besitzen.
Konkrete Klasse:
Klasse, die direkte Instanzen besitzen kann
(„Instanziierbare Klasse“)
Nur konkrete Klassen können Blattklassen im Vererbungsbaum sein!
Eine abstrakte Klasse kann sowohl abstrakte Operationen als auch nicht abstrakte
Operationen definieren.
Abstrakte Operation:
Eine Klasse kann nur das Protokoll einer Operation definieren,
ohne eine entsprechende Methode zu implementieren.
51

Kennzeichnung abstrakter Operationen:
{ abstract } oder Signatur in italics
Ist eine Operation nicht als abstract gekannzeichnet, muß die Operation implementiert werden.
52

Parametrisierte Klassen
Parameter
Klasse mit gebundenem Parameter
53

D
D
y
y
n
n
a
a
m i
i
s
s
c
c
h
h
e
e
M o
o
d
d
e
e
l l
l
i
i
e
e
r
r
u
u
n
n
g
g
Instanzen als Laufzeitobjekte
• Instanzobjekt ist Laufzeitobjekt (Ebene M0),
belegt Speicherplatz, besitzt Identität und Lebensdauer
• Klassen können auch Laufzeitobjekte sein ( -> Klassenobjekt)
Objekte können benannt werden (Sichtbarkeitsbereiche)
– global (Klassen)
– Paket-lokal (Klassen)
– Klassen-lokal
– Methoden-lokal
Typkompatibilität:
Mit einem Namen kann zeitlich wechselnd
- ein Objekt der definierten Klasse oder
- ein Objekt einer der Subklassen dieser Klasse
assoziiert sein
54

Objekte befinden sich in Zuständen
= Vereinigung der Werte aller Attribute zu einem bestimmten Zeitpunkt
Objekte können untereinander mittels Nachrichten kommunizieren
• Methodenaufrufe
• Ereignisse
(mit Antwort)
(ohne Antwort, Antworten sind selbst
Ereignisse)
Bei der Abarbeitung von Methoden oder der Reaktion auf Ereignisse
(in sog. Handlern) können Objekte ihren Zustand ändern.
Ereignisse und Zustände
Ereignis:
• etwas, das in einem bestimmten Augenblick passiert. Ein Ereignis hat keine Dauer.
• Übertragung von Informationen von einem Objekt zu einem anderen.
Ereignisse können in Ereignisklassen gruppiert werden.
55

Beispiele:
Ereignisklassen mit Attributen
Telefonhörer abgehoben.
Ziffer gewählt (Ziffer).
Maustaste gedrückt (Taste, Ort).
Flug fliegt ab (Datum, Fluglinie, Flugnummer).
Instanzen der Ereignisklassen
Telefonhörer abgehoben.
Ziffer gewählt (4).
Maustaste gedrückt (ShiftKey, (100,100))
Flug fliegt ab (15 Jan, Dresden-Bonn, LH1319)
Zustand:
• entspricht der Zeitspanne zwischen zwei von einem Objekt empfangenen
Ereignissen. Zustände repräsentieren Zeitspannen.
Der Zustand eines Objekts bestimmt die Reaktion des Objekts auf ankommende Ereignisse.
Reaktionen können Aktionen und/oder Zustandsänderungen sein.
56

Szenario:
Folge von Ereignissen, die bei einer ganz bestimmten Ausführung
eines Systems auftritt.
• kann alle Ereignisse eines Systems betreffen
• kann Ereignisse betreffen, die bestimmte Objekte eines Systems beeinflussen
oder von bestimmten Objekten erzeugt werden.
Ein Szenario erhält man durch Aufzeichnung bei der Ausführung eines Systems oder
durch gedankliche Vorausplanung der Aufzeichnung.
Ereignispfad:
zu einem Szenario werden Sender- und Empfängerobjekte
zu jedem Ereignis bestimmt und mit den Ereignissen entsprechend der
Ereignisreihenfolge in einem Ereignispfad-Diagramm dargestellt.
Merke:
Ein Szenario ist für ein dynamisches Modell das gleiche, wie ein Instanzendiagramm
für ein Objektmodell!
57

Ein Sequenzdiagramm zeigt das Verhalten von Objekten und berücksichtigt
die Interaktion mit anderen Objekten durch Austausch von Nachrichten.
-> zeigt Objekte mit Lebenslinie und Nachrichtenaustausch
-> Interaktionen gehen stets von Objekten bzw. Prozessen aus
60

Statechart-Modelle/-Diagramme
Zustand: (state) ist die Verfassung (im Verlaufe des Lebens) eines Objekts, in der es
• einer Bedingung genügt
• eine Aktivität ausführt (andauernd)
• auf ein Ereignis wartet
Ein Zustand ist einer Klasse zugeordnet.
Nicht jede Änderung eines Attributwertes wird als Zustandsänderung registriert.
Transition: durch ein Ereignis verursachte Zustandsänderung eines Objekts (Zustands-
Übergang). Wenn ein Ereignis empfangen wird, hängt der nächste Zustand
sowohl vom aktuellen Zustand als auch vom empfangenen Ereignis ab.
Zustandsautomat: Graph, bestehend aus Zuständen (Knoten) und Transitionen (Kanten),
der die Reaktion eines Objekts einer Klasse auf den Empfang von „äußeren Stimuli“
beschreibt. Zustandsautomat ist einer Klasse oder einer Operation zugeordnet.
62

Notation:
Startzustand
Endzustand
event(argument … ) [ bedingung ] / operation(argument … )
Alle von einem Zustand ausgehenden Transitionen müssen unterschiedlichen
Ereignissen entsprechen!
Interpretation:
• Wenn sich ein Objekt in einem Zustand befindet, und ein Ereignis tritt auf, mit dem
eine seiner Transitionen beschriftet ist, geht das Objekt in den Zustand am Ende der
Transition über: Die Transition feuert.
• wenn ein Ereignis auftritt, für das es keine vom aktuellen Zustand ausgehende
Transition gibt, wird das Ereignis ignoriert.
63

Beispiel: Dusche-Badewanne
64

Beispiel: Flug-Reservierung
65

Beispiel: Klimaanlage
66

Komposite Zustände:
Ein Zustand kann dekomponiert werden
• mittels and in parallele Teilzustände
• mittels or in sich gegenseitig ausschließende Teilzustände
Eine Verfeinerung ist nur auf einem dieser beiden Wege möglich.
67

Unterzustände:
- sind die in einem kompositen Zustand enthaltenen Zustände
- können sein
➔
einfache Zustände,
➔
komposite Zustände oder
➔ Pseudozustände
Es entsteht ein Zustandsbaum (Hierarchie)
Kompositum
B
C
D
E F G H
69

Trigger – Events, die Transitionen auslösen
70

► Trigger dienen als Auslöser für Transitionen
Signal-Trigger:
• A möchte eine asynchrone Nachricht an B übermitteln
• SendInvocationEvent bei A → löst SignalEvent bei B aus
Call-Trigger:
• A möchte eine Operation bei B aufrufen
• CallInvocationEvent bei A → löst CallEvent bei B aus
Time-Trigger:
• Auslösen einer Transition zu bestimmter Zeit oder nach
• bestimmter Zeitdauer
Change-Trigger:
• Wird ausgelöst, wenn sich der Wert eines Change Expression
von false auf true ändert. Die Transition wird bei Änderung des
Wächters (guard) auf true ausgeführt
Any-Trigger:
• Zusammenfassung aller Trigger außer denen, die an den anderen
ausgehenden Transitionen des betrachteten Zustandes existieren
71

Pseudozustände
●
Komplexe Beziehungen zwischen Zuständen
einfach darstellen
●
Transitionen dürfen über einen oder
mehrere Pseudozustände gehen
Beispiel:
Beispiel:
Wegsuche
Wegsuche
in
in
einem
einem
Labyrinth
Labyrinth
An
An
einer
einer
Kreuzung
Kreuzung
muss
muss
sich
sich
der
der
Läufer
Läufer
für
für
eine
eine
Richtung
Richtung
entscheiden:
entscheiden:
links,
links,
gerade,
gerade,
rechts,
rechts,
zurück.
zurück.
Nach
Nach
einer
einer
entsprechenden
entsprechenden
Drehung
Drehung
läuft
läuft
der
der
Läufer
Läufer
so
so
lange,
lange,
bis
bis
er
er
an
an
eine
eine
neue
neue
Kreuzung
Kreuzung
oder
oder
ans
ans
Ziel
Ziel
kommt.
kommt.
72

Pseudozustand „Kreuzung“
73

Pseudozustand „Entscheidung“
74

Aktivitäten-Diagramm
75

Beispiel: Autovermietung
Rücknahme
78

3 Implementation von UML-Modellen
Java-Applikationen
Programme in einer virtuellen Maschinensprache: JVM
Interpretative Verarbeitung
java MyApplication
Compilation: MyApplication.java MyApplication.class
import java.io.*;
javac MyApplication.java
public class MyApplication{
public static void main(String args[]){
System.out.println("Hello World");
for (int i = args.length -1; i>= 0; i--)
System.out.println(args[i]); } }
79

Interfaces in Java
Syntaktisch analog Klassen
(class → interface)
Reine Schnittstellen, enthalten keine Implementationen
Ausschließlich abstrakte Methoden und Konstanten
Eine Klasse kann ein oder mehrere Interfaces durch Implementierung erben
(Ersatz für Mehrfachvererbung)
Wenn eine Klasse ein Interface implementiert, dann muss sie alle Methoden
überschreiben
Die Eigenschaft, ein Interface zu implementieren, wird an Nachfahren der Klasse vererbt.
80

Implementation von Assoziationen und Aggregationen
1:1 – Beziehungen: Instanzvariable, Typ ist Klasse der zu verwaltenden Objekte
1:n – Beziehungen: Vektoren und Hashtabellen (java.util)
Vector v = new Vector(10);
Methoden:
void addElement(Object o)
void insertElement(Object o, int index)
void removeElement(Object o)
void removeElementAt(int index)
int size()
81

import java.applet.*;
import java.awt.event.*;
import java.awt.*;
Event-Handling
public class AcEvDemo2 extends Applet implements ActionListener{
public void init() {
System.out.println("Hello world!");
Button bopen = new Button("open");
Button bclose = new Button("close");
bopen.addActionListener(this);
bclose.addActionListener(this);
add(bopen);
add(bclose);
System.out.println("I am waiting for events.");
}
public void actionPerformed(ActionEvent evt){
if (evt.getActionCommand().equals("open")){
System.out.println("action in open");
}
if (evt.getActionCommand().equals("close")){
System.out.println("action in close");
}
}
}
82

4 Systemarchitekturen
System
Logische Struktur
(Klassen, objektbasiert)
Physische Struktur
(Komponenten, nicht objektbasiert)
Komponentenmodelle
UML: Komponentendiagramme
Subsystem :
package
84

Architekturentwurf
(nach H. Balzert)
► Grundlegende Entwurfsentscheidungen
Wahl:
- Plattform (BS)
- Programmiersprache (OO)
- GUI-System (Bibliotheken, z.B. AWT, Swing, SWT)
- Datenhaltung / Datenbank
► Schichtenarchitektur
Drei-Schichten-Architektur
- GUI-Schicht
- Fachkonzeptschicht (Geschäftsklassen,
Zugriffe auf die Datenhaltungsschicht)
- Datenhaltungsschicht
85

OK
86

Verteilungsmodelle
Modellierung verteilter Anwendungen: Auf Knoten laufen Prozesse ab
87

5 Der Softwareentwicklungsprozess
Anwendungsfallanalyse
Ein Anwendungsfall (use case) beschreibt Interaktionen zwischen Anwendern und dem
Anwendungssystem, die notwendig sind, um einen Arbeitsgang durchzuführen.
es sind Anwendungsfälle und Akteure zu identifizieren.
88

Methodische Aspekte der Modellierung
In der Analysephase sind folgende Aktivitäten erforderlich:
→ Zerlegung des Anwendungsbereiches in Unterbereiche
→ Analyse und Spezifikation des geforderten Systemverhaltens
Während der Problembereichsanalyse werden zunächst „Geschäftsklassen“ modelliert.
„Fachklassen“ beschreiben im Unterschied dazu implementierungs-technische
Sachverhalte.
Zur Entwicklung eines Objektmodells wird von Rumbaugh folgendes Vorgehen empfohlen:
► Objektklassen identifizieren
► ein Data Dictionary vorbereiten
► Assoziationen zwischen Objektklassen identifizieren
► Attribute identifizieren und zu Objektklassen hinzufügen
(Operationen erst spät beim Spezifizieren des Zustandsmodells hinzufügen)
► Klassen mittels Vererbung organisieren
► Zugriffspfade testen
► das Gesamtmodell in einem iterativen Prozess verfeinern
► Klassen zu Paketen (Teilsystemen) gruppieren
91

Qualitätssicherung
Die Qualitätssicherung umfasst
● die Planung/Durchführung von Qualitätssicherungsmaßnahmen (QSM) ,
● die Kontrolle der Einhaltung von Standards (ISO 9000, ... ) und
● die Qualitätsbewertung anhand von Metriken.
92

Projektmanagement & Prozessmodellierung
• Maßnahmen zur Planung, Verfolgung und Qualitätssicherung einzelner Projekte und
von Projektfamilien
• Prozessmodellierung: Modellierung und Programmierung des Software-
Entwicklungfsprozesses
(Rollen, Aktivitäten, Dokumente, Ressourcen)
93

Konfigurationsmanagement
► Ziele des KM:
● Im SEP entstehende Ergebnisse (Artefakte: Dokumente, Modelle, Code)
sicher verwalten
● Zugriffskontrolle für verteilt arbeitende Entwickler
● Kontrolle über Veränderungen an Artefakten im Laufe der Entwicklung
► Das KM umfasst Aufgaben wie
● die Kontrolle der entwickelten Quellprogramme
● die Bereitstellung von „Build“-Funktionalität
● das Release-Engineering
► KM = Regelwerk, mit dem KM-Prozess beschrieben wird
96

Versionsverwaltungssysteme
► Versionsverwaltungssysteme stellen dem KM-Prozess ein Repository
zur Verfügung
► ermöglichen die Aufzeichnung der Entwicklungsgeschichte von
Programmdokumenten in Projekten und unterstützt die Gruppenarbeit
(check-out – check-in).
► Das Concurrent Versions System (CVS) ist ein System, das das Versions-
Management auf der Ebene von Quellprogrammen unterstützt (Open Source).
→
→
→
keine Deltas auf der Ebene von Binaries!
nur Dateien versionierbar, keine Verzeichnisse
keine Unterstützung von Transaktionen
► Subversion (Open Source) ist ein seit 2004 verfügbares Nachfolgesystem zu CVS.
97

Client-Server-Architektur von Subversion:
Abbildung nach G. Popp
98

6 Wiederverwendung
Die Verwendung objektorientierter PS allein garantieren keine Verbesserung der
Wiederverwendbarkeit
Framework:
Sammlung individueller Komponenten mit definiertem Kooperationsverhalten
zur Lösung einer Aufgabe
Whitebox-Framework:
Blackbox-Framework:
Anpassung durch Subklassenbildung + Compilation
Anpassung zur Laufzeit durch unterschiedliche
Instanziierung
99

Entwurfsmuster
• Gamma et al. haben einen Katalog von 23 Entwurfsmustern beschrieben.
• Entwurfsmuster sind typischerweise in Anwendungen vorkommende Kombinationen
von Klassen zu größeren Einheiten, unabhängig von der Programmiersprache.
100

101

102

103

104

Entwurfsmuster „Beobachter“
105

Entwurfsmuster „Kompositum“
106

Die Model-View-Controller-Architektur (MVC)
View
Model
Controller
• Modell-Objekt stellt das Anwendungsobjekt dar
• View-Objekt stellt die Bildschirmrepräsentation dar
• Controller-Objekt bestimmt die Reaktion auf Benutzereingaben
→ Veränderung des Modells
107