Semantik und Verification der Datenfluss in UML 2

Technische Universität München
Fakultät für Informatik
Hauptseminar: Semantik der UML V2.0
Semantik des Objektflusses
Ye Shen
Betreuer: Herr Peter Graubmann
Chair: Prof. Manfred Broy
1.Einführung
1.1 Historie von UML
1.2 UML 1.x und UML2.0 Superstructure&Infrastructure UML
1.3 Motivation und Ziel
2. Aktivitätsdiagramm in UML 2.0
2.1 Abstrakte Syntax
2.2 Konkrete Syntax für Objektknoten, Objektfluss und
Parameter
3 . Semantik des Objektflusses
3.1
3.2
3.3
3.4
3.5
Die Begriffe „Semantischer Bereich“ und
Petri-Netze
Gefärbte Petri-Netze
Semantischer Bereich
Semantische Abbildung
4. Analyse des Objektflusses
4.1 Verifikation
4.2 Analyse
4.3 Quantitative Analyse
5. Zusammenfassung
2
„Semantische Abbildung“
1 Einführung
1.1 Historie von UML
Modelle sind ein natürlicher Weg, um komplexe Vorgänge und Systeme zu verstehen, zu
untersuchen, aber auch zu planen und sie dann in die Realität zu überführen. Seit
Mitte/Ende der 80er Jahren wurden OOAD Techniken (Objektorientierte Analyse- und
Designtechniken) parallel zu Objektorientierten Progammierensprachen entwickelt. Für
die verschiedensten Anwendungsbereiche sind eine Reihe von Methoden entwickelt
wurden. Die drei wichtigen Vertreter Booch, Rumbaugh (OMT - Object Modelling
Techniques) und Jacobson (OOSE – Object-Oriented Software Engineering) haben diese
auseinanderstrebenden Entwicklungen beendet und Mitte der 90er begonnen, ihre
jeweiligen Objektorientierten Analyse- und Designtechniken zur Unified Method (UM) zu
vereinigen.
Die Unified Modeling Language (UML) ist eine Sprache und Notation zur Spezifikation,
Konstruktion, Visualisierung und Dokumentation von Modellen für Softwaresysteme.
Abbildung 1: Historische Entwicklung objektorientierter Methoden und der UML.
1.2 UML 1.x und UML 2.0: Superstructure&Infrastructure
UML 1.2 tauchte im Jahr 1998 auf, UML 1.3 im Jahr 1999, UML 1.4 im Jahr 2001, und
UML 1.5 im Jahr 2002.
UML 2.0 zeigt die größten Veränderungen, die bis jetzt in UML vorgekommen sind.
UML 2.0 ist formal in folgende Teilbereiche gegliedert:
Infrastructure (Kern der Architektur, Profles, Stereotype)
3
Superstructure (Statische und dynamische Modellelemente)
OCL (Object Constraint Language)
Diagramm Interchange Format (UML Austauschformat)
Unterschiede zwischen UML1.x und UML 2.0
1. Klassendiagramm
2. Sequenzdiagramm
3. Zustanddiagramm
4. Aktivitätsdiagramm
Innerhalb dieser Präsentation werden nur Aktivitätsdiagramme berücksichtigt.
Definition des UML 1.x Aktivitätsdiagramms
„Aktivitätsdiagramme beschreiben die Aktivität von Objekten während des
Programmablaufes. Dabei beschreibt eine Aktivität einen einzelnen Schritt innerhalb
eines Systems. Ein Aktivitätsdiagramm ist eine spezielle Form eines
Zustandsdiagrammes, wobei die Zustände der Modellelemente in der Mehrzahl als
Aktivitäten definiert sind.“
Definition des UML 2.0 Aktivitätsdiagramm
„Ein Aktivitätsdiagramm beschreibt einen Ablauf und wird definiert durch verschiedene
Arten von Knoten, die durch Objekt- und Kontrollflüsse miteinander verbunden sind. Es
werden Aktions-, Objekt- und Kontrollknoten unterschieden.“
Die Semantik der Aktivitätdiagramme entspricht jetzt weitgehend der
Petrinetzsemantik. gibt Durch diese grundlegende Änderung der Definition ergeben sich
sehr viele weitreichende Veränderungen im Detail.
1.3
Motivation und Ziel
Wie oben gezeigt, hat sich im Vergleich zu UML 1.5, die Syntax des Aktivitätsdiagramms
außer beim Kontrollfluss dramatisch geändert. Die konkrete Syntax des Objektflusses,
alle abstrakte Syntax und insbesondere die Semantik sind davon beeinflusst.(in UML 1.5
ist das Aktivitätsdiagramm als eine spezielle Form eines Zustandsdiagramms definiert,
jetzt gibt es keine solche Beziehung mehr.) „Activities are redesigned to use a Petri-like
semantics instead of state machines.“ In diese Präsentation werden wir sehen, wie
Petrinetze für diese Ziel dienen können. Die traditionellen Petri-Netze sind dafür nicht
geeignet, wir werden eine andere Netzklasse benutzen, die „gefärbte
Petri-Netze“ genannt wird.
2
Aktivitätsdiagramme in UML 2.0
In diesem Abschnitt diskutieren wir die Aktivitäten des Aktivitätsdiagramms in UML 2.0.
Die Unterschiede zwischen UML 1.5 und UML 2.0 sind insbesondere zu beobachten. Als
Beispiel benutzen wir immer dasselbe Diagramm, das in der Abbildung 6 gezeichnet ist.
4
2.1 Abstrakte Syntax
Das zentrale Konzept das den Aktivitätsdiagrammen zugrundeliegt ist jetzt die Aktivität
und ersetzt den „ActivityGraph“ in aus UML 1.5. Aktivität ist keine Unterklasse von
Zustand, sondern „redesigned to use a Petri-like semantics instead of state machines.“
Abbildung 2 Abhängigkeit der Aktivitätspakete
Das Konzept der Aktivität betont die Abfolge von Ereignissen und die Bedingungen für
ihre Koordinierung zur Beschreibung des lower-level Verhaltens. Die beiden Konzepte
werden normalerweise Kontrollfluss und Objektfluss Model genannt. Die Aktionen, die
vonm Aktivitätd-Modell koordiniert, kann initiiert werden, wenn andere Aktionen fertig
ausgeführt sind.
Aktionen und Aktivitäten
Eine Aktionsausführung entspricht der Ausführung eine einzelnen Aktion innerhalb einer
Aktivität; ähnlich, eine Aktivitätsausführung ist die Ausführung einer Aktivität. Sie enthält
auch die Ausführung der Aktionen innerhalb der Aktivität. Jede Aktion kann in einer
Aktivität null, ein, oder mehrmals ausgeführt werden. Eine Ausführung ist nicht
augenblicklich durchgeführt, sondern braucht eine Zeitspanne.
Aktivitätsdiagramme bieten nicht die Spezifikation eines Zeitabstands, sondern
5
beschreibtdn nur den Ablauf einer Ausführung. Aktivitäten und andere Gruppierungen der
Aktionen müssen in einigen Schritten ausgeführt werden.
Mindestens, Aktionen brauchen die Verbindung zur Daten, sie sollen die Daten
transformieren und testen. Die Aktivitäten-Spezifikation (higher levels) erlaubt einige
threads für Kontroll-Ausführung auf einmal und ein Synchronisations-Mechanismus
sichern, das die Aktivitäten werden in eine spezifizierten Reihenfolge ausgeführt werden.
Semantik basiert auf aktuellen Ausführungen und kann in eine verteilt Implementierung
abgebildet werden. Manche Implementierungen können Objekte zusammen in eine
Aufgabe gruppieren und folgerichtig ausführen.
BasicActivites
Der erste Level “BasicActivities “ stützt die Modellierung von traditionelle sequentiellen
Flussdiagrammen ab. Kontrollsequenz ist inklusiv, aber fork und joins sind exklusiv.
Entscheidungen und merges sind abgestützt.
IntermediateActivities
Der “intermediate level “ stützt die Modellierung des Aktivitätsdiagramms ab, die aktuelle
Kontroll- und Objektflüsse enthaltet. Dazu werden „Basic Activities“ benötigt.
Aus Abbildung 3 können wir ersehen, dass Aktivitäten Aktionen, Aktivitätsknoten und
-kanten enthalten. Objektknoten ist eine Unterklasse von Aktivitätsknoten. Und Klasse
Aktivitätsknoten enthält Ausführbarknoten, Objektknoten und Kontrollknoten.
Von Abbildung 7 sehen wir, Objektfluss ist eine Unterklasse von Kante.
Abbildung 8 zeigt uns alle Unterklassen der Kontrollknoten , das sind: Startknoten,
Endknoten, Entscheidungsknoten, Mergeknoten. Forkknoten und Joinknoten.
Startknoten
„Startknoten
Ein Startknoten ist ein Startpunkt eines Ablaufes in einem
Aktivitätsdiagramm. Der Begriff Anfangsknoten ist synonym zu verwenden.“
Endknoten
„Ein Endknoten beendet den beschriebenen Ablauf, d.h. alle Aktionen und den
Kontrollfluss.“
Entscheidung
„Eine Entscheidung ist ein Kontrollknoten mit einem oder mehr ausgehenden
Kontrolflüssen, an dem aufgrund von Bedingungen entschieden wird, welcher von
mehreren weiterführenden Kontrollflüssen fortgesetzt werden soll.“
Merge
„Eine Merge ist ein Kontrollknoten, bei dem auf alle eingehenden Kontrollflüsse gewartet
wird ,bevor der Kontrollfluss fortgesetzt wird.“
6
Fork
„Eine Fork ist ein Schritt im Ablauf, an dem en eingehender Kontrollfluss ohne
Bedingungen sofort in mehrere ausgehende nebenläufige Kontrollflüsse geteilt wird.“
Join
„Eine Join ist ein Kontrollknoten, bei dem jeder von mehreren eingehenden
Kontrollflüssen sofort zu einem gemeinsamen ausgehenden Kontrollfluss führt.“
Abbildung 3 Klasse Diagramm (Knoten)
7
Abbildung 4 Fluss
Abbildung 5 Kontrollknoten
Angenommen eine Aktivität besteht aus <Aktivitätsknoten,Kante>, die die Aktivitätsknoten
und Kante die jeweilige Metaklasse wieder unterteilen. Das heißt auch Aktivitätsknoten ist
ein Tupel <EN,iN,fN,BN,CN,ON>
EN
die Menge der AusführbarKnoten
iN,fN die Startknoten und die Endknoten
BN
die Menge der Branchknoten, inklusiv Mergeknoten und Entscheidungsknoten
CN
die Menge der nebenläufigen Knoten, subsumiert Forkknoten und Joinknoten
ON
die Menge der Objektknoten
Und Kante ist ein Paar <AE,OF>:
AE
die Menge Kanten zwischen den Ausführbarknoten und den Kontrollknoten
OF
die Menge der Objektfluss zwischen den Ausführbarknoten und einerseits und
8
Objektknoten andererseits.
Später werden wir immer diese abstrakte Syntax benutzen, um eine Aktivität darzustellen.
In den folgenden Abschnitten werden wir immer das Beispiel aus Abb 6 nehmen um die
Konzepte und Methoden klar zu machen. Dieses Beispiel beschreibt einen
Verkaufsprozess. Das Geschäft bekommt die Bestellung von einem Kunden. Dann wird
das Geschäft sich entscheiden, ob die Bestellung akzeptiert werden kann. Wenn Ja,
werden zwei nebenläufige Prozesse ausgeführt. Zum einen sendet das Geschäft dem
Kunde die Waren. Zum anderen wird eine Rechnung auch zum Kunde geschickt. Dann
muss der Kunde dafür bezahlen. Wenn beide Sachen erledigt sind, können wir den
Waren-Verkaufensprozess abschließen.
Abbildung 6 ein
Objektdiagramm
einfaches
Aktivitätsdigamm
2.2 Konkrete Syntax
Der UML-Standard erlaubt drei verschiedene Notationen für den Objektfluss.(vgl.
Abbildung 7)
Abbildung 7 Konkrete Syntax für den Objektfluss: UML Notation (links),und
alternative quivalente UML 2.0 Notationen (alle andere)
9
mit
Definition für Objektknoten, Objeckfluss
„Ein Objektfluss gibt an, dass ein Objekt oder eine Menge von Objekten existiert.“
„Ein Objektfluss ist wie ein Kontrollfluss, bei dem jedoch Objekte (Objekt-Token)
transportiert werden.“
Die erste Alternative: Objektknoten können durch Rechtecke dargestellt werden. Der
Pfeil führt von oder zu einem Objektknoten. Das ist ähnlich wie in der UML 1.5. Nur der
gestrichelte Pfeil ist durch einen durchgezogenen Pfeil ersetzt worden.
Die zweite Alternative: Diese Version ist sehr praktisch. Sie erlaubt, einen Objektfluss an
ein Kontrollfluss anzuhängen. Man kann erst den Kontrollfluss spezifizieren, und später
den Objektfluss wahlweise noch beifügen.
Es gibt aber gleichzeitig auch einen Nachteil. Es ist nicht ganz klar, was die Notation
wirklich bedeutet. Zwei Erklärungen sind möglich. Erstens, Die Verknüpfung eines
Objektknoten mit einer Kante wird interpretiert als: Objektfluss fließt in den Objektknoten
rein und dann wieder herraus. Zweitens: Die Notation bedeutet, die Kontrollfluss-Kante
wird durch zwei Objektflüsse ersetzt. Diese Alternative ist aber nur eine andere
Schreibweise für die erste Alternative.
Die dritte Alternative: Diese Alternative spezifiziert Pins (Unterklasse von Objektknoten)
als die „Paramentern“ der Aktivität.
Kfz.Fahrzeug
Protokoll:Ubergabeprotokoll
Parameterdeklaration
Kfz
Eingangs-parametern
Kfz-Zus
tand
Kfz
Übergeben
Abbildung 8. Notation von Parametern
Protokoll
AusEingangs
parametern
Pins können wiederum zu Gruppen zusammengefasst werden. Innerhalb einer
Parametergruppe müssen alle definierten Objekte bereitstehen, bevor die Aktivität startet
und alle Objekte innerhalb einer Gruppe müssen auch bereitgestellt sein, bevor der
Kontrollfluss weiter geht.
10
P1
P3
Aktions
knoten
P4
P2
P5
Abbildung 9 : Parametergruppen
Sofern mehrere Parametergruppen definiert werden, ist zu beachten, dass der
Kontrollfluss immer nur in einer von mehreren Parametergruppen fließen kann.
Abbildung 10 eine spezifizierte Version für die Aktivitätsdiagramm der Abbildung 6
Am End dieses Abschnitts geben wir eine andere spezifizierte Version für das
Aktivitätsdiagramm der Abbldung 6.
Die effect reject und guard accept sind schon entfernt. Für eine formale Sprache ist eine
vollständige Beschreibungen benötig. Reject und accept stellen menschliche
11
Entscheidungen im Aktivitätsdiagramm dar und bleiben offen. Darum wurden sie in der
Petrinetzdarstellung entfernt.
Nehmen wir Abbildung 10 zu klären. In diesem Beispiel gibt es drei Arte von Anschriften.
Erstens, es gibt Typ Deklaration auf Objektknoten (sie werden colors der bezüglichen
CPN Stellen in unserer Interpretation). Manche Objektknoten deklarieren auch eine
Variable (die wird in unseren Interpretation o genannt).
Zweitens, es gibt effect, Selection und Transformation in geschweiften Klammern auf
Aktivitätskanten. Sie funktioniert in einem gegebenen „name space“, innerhalb diese
„name space“ ändern sie den Status einiger Objekte.
Dritte, es gibt guard-Funktionen in eckigen Klammern auf Aktivitätskanten. Sie rufen die
name space ab, und können in den Zustand eines Objekts lesen.
3
3.1
Semantik des Objektflusses
Begriff von „semantischer Bereich“ und
„semantische
Abbildung“
Um miteinander kommunizieren zu können, brauchen wir den „Ausdruck“. Es ist gut,
wenn jede Kommunikationsteilnehmer denselben Ausdruck benutzt. Ein Semantik einer
Sprache Ls, besteht aus zwei Anteilen: ein „Semantischer Bereich“, die bezeichnen wir
normalerweise mit Sl oder einfach S, wenn es keine Konfusion gibt. Und ein „semantische
Abbildung“ , die von Syntax nach „Semantischer Bereich“, ist mit Ml oder M bezeichnet. In
der Semantik einer Sprache geht es um die Bedeutungen von einem Ausdruck. Diese
Bedeutung muss ein Element in einer gut definierten Domäne sein. z.B die Bedeutung
eines arithmetischen Ausdrucks in der Sprache <Exp> ist ein Nummer N. Hier benutzen
wir S=N als semantischer Bereich von <Exp>.Und semantische Abbildung hängt dann
jeden Ausdruck <Exp> mit eine Nummer zusammen. M:<Exp>Æ N
Language
+
Syntax
=
Notaion
semantics
+
Semantischer
Bereich
Abbildung 11 Stuktur einer Sprache
12
Semantische
Abbildung
3.2
Petri-Netze
Petri-Netze sind ein häufig benutzte Modellierungssprache zur Darstellung von Systemen
und den Abläufen innerhalb dieser Systeme. Heute gibt es eine Menge von
Netz-Varianten, die auf C.A. Petris Arbeit in den frühen 60er Jahren basieren. Allen
Petri-Netzen gemeinsam ist ihr grundsätzlicher Aufbau. Sie bestehen aus
•
•
•
Systemzuständen (Stellen)
Zustandsübergängen (Transitionen)
gerichteten Kanten zwischen Stellen und Transitionen, die diese miteinander
verbinden
Eine Petri-Netz ist ein Tupel
PN=(P,T,A)
P ist eine endliche Menge von Stellen.
T ist eine endliche Menge von den Transitionen.
A ist eine endliche Menge von gerichteten Kanten zwischen Stellen und Transitionen
In den Stellen des Netzes können sich mehrere Marken befinden, die den Zustand des
Systems anzeigen.
P∩T=P∩A=T∩A=
In den Stellen des Netzes können sich mehrere Marken befinden, die den Zustand des
Systems anzeigen. In einfachen Petri-Netzen haben die in den Stellen abgelegten Marken
keine besonderen Eigenschaften. Eine Transition kann schalten, wenn in ihren
Eingangsstellen genügende Marken vorhanden sind. Das Schalten entfernt in diesem
Beispiel je eine Marke aus den Eingangsstellen und fügt in jeder Ausgangsstelle eine
Marke hinzu.
Abbildung 12 ein Beispiel von Petri-Netze
Das Hauptproblem der einfachen Petri-Netze ist ihr Umfang. Viele Situationen erfordern
eine umfangreiche Netzdarstellung.
13
3.3
Gefärbte Petri-Netze
Um das Problem der einfachen Petri-Netze zu lösen wurden high level Petri-Netze
entwickelt. Gefärbte Petri-Netze sind high-level Petrin-Netze, die unterschiedliche Arten
von Markierungen erlauben.
In der neuer UML 2.0 wird festgestellt, Aktivitäten„ use a petri-like semantics instead of
state machines”.Aus pragmatischem Grund nehmen wir hier gefärbte Petri-Netze als
„Semantischer Bereich“.
Abbildung 13 Ein abstraktes Beispiel von CPN
Sehen Sie Abbildung 13. Im diese Abbildung, das Gewicht an der Kante der
Ausgangsstelle P3 ist 2. Deshalb werden zwei Marken beim Schalten in die
Ausgangsstelle hinzugeführt.
3.4
Semantischer Bereich
Definition 3.4 (Struktur der Gefärbten Petri-Netze)
(CPN) ist ein Tupel <N,SigAlg,color,guard,effect> mit
N ist ein Petri-Netz <P,T,A> von den Stellen (places) den Transitionen (transitions) and
Kanten
SigAlg ist eine ∑ Algebra <∑,Op> von Marken und Operationen
Color
ist eine totale Funktion P Æ ∑ setzt eine Marke zu jeder Stelle
Guard ist eine totale Funktion T ÆExpr setzt einen booleschen Ausdruck zu jeder
14
Transition fest, vorgegebener Wert ist die Konstante tt.
Effect
ist eine totale Funktion A Æ Expr setzt einen Ausdruck zu jeder Kante, ihr Typ ist
die „color“ der Stelle der Kante.
Color, guard und effect können teilweise spezifiziert werden, mit vorgegebener Wert
Schwarzpunktmarke. Das heißt wenn color(p) undefiniert ist, nehmen wir
color(p)=MARKEN(TOKEN).Eine Markierung eines Petri-Netze ist eine Multimenge von
{<p,v>|p P,v color(p)}
3.5
Semantische Abbildung
In Beziehung zum Kontrollfluss, AusführbarKnoten werden Transitionen, Kontrollknoten
werden Stellen oder Transitionen, und Aktivitätskanten werden Netzkanten,
möglicherweise mit Hilfstransitionen oder Stellen. In Beziehung zum Objektfluss,
Objektknoten werden Netzstellen und Objektfluss werden Netzkanten.
Ausführbarknoten
UML
Aktivitaet
Petri-Netze
Kante
UML
Petri-Netze
Aktivität
Kontrolknoten
außer:
Fork/join
außer das:
Hilfstransaktion
Objektknoten
Typ
Tpy
Objektfluss
expr
expr
Abbildung 14 Die Intuition von semantische Abbildung für Kontrol und Objekt Fluss
der Aktivitäten.
Um das oben gezeichnete Beispiel zu analysieren, müssen wir die abstrakte Syntax einer
Aktivität (Aktivitätsknoten, Aktivitätskanten) in ein CPN <N,SigAlg,color,guard,effect> mit
einer Funktion [_]
abbilden. Diese semantische Funktion ist so definiert:
P={iN,fN}∪BN∪ON∪{Pe∈AE,{e.source,e.target} ⊆EN∪CN}
P ist eine endliche Menge von den Stellen. P ist gleich Startknoten und Endknoten,
vereinigt mit BN (den Branchknoten) und ON (den Objektknoten), und vereinigt mit Stellen,
die zusätzlich zwischen Kontrollknoten eingefügt werden müssen, um die
Petri-Netz-Syntax zu realisieren.
T=EN∪CN∪{Te|e∈AE, {e.source,e.target}⊆BN∪{iN,fN}}
15
T ergibt sich aus den ausführbaren Knoten vereinigt mit CN (den nebenläufigen Knoten:
fork ,join) und zusätzlichen Transitionen, die als Hilfstransitionen eingeschoben werden
müssen. Diese zusätzlichen Transitionen werden zwischen Branch-, Start- und
Endknoten und den anderen Knoten aus dem Aktivitätsdiagramm eingefügt.
A={<e.source.xe>,<xe,e.target>|e∈AE,xe∈P∪T}∪{<x,y>|<x,y>
∈AE∧(x∈P,y∈T)∨(x∈T,y∈P)}
A ist eine endliche Menge von Kanten zwischen Stellen und Transitionen. Sie besteht aus
zwei Teilen.
Den ersten Teil bilden Petri-netz-Kanten, die sich aus den Kanten des
Aktivitätsdiagramms ableiten, die zwischen den ausführbaren bzw. den Kontrollknoten
bestehen, wenn Hilfstransitionen bzw. -Stellen eingeschoben worden sind. Den zweiten
Teil bilden die Kanten des Aktivitätsdiagramms, die unmittelbar in das Petri-Netz
umgesetzt werden können. (Vergleichen Sie bitte Abbildung 14).
SigAlg=<{o.type|o∈ON},{a.transformation|a∈OF}>
ist eine ∑ Algebra <∑,Op> von Marken und Operationen
color={oÆo.type|o∈ON}
Die Funktion color setzt eine Markierung, die von Objektknoten in die Markierung
abgebildet, zu jeder Stelle.
Effect={aÆa.transformation|a∈OF}
setzt einen Ausdruck zu jeder Kante; ihr Typ ist die „color“ der Stelle der Kante.
Guard={tÆ∧<a,t>∈OF a.selection ∧
∧<t,a>∈OF a.selection |a∈OF}
Für jeden Objektfluss, der in eine Transition führt bzw. aus einer Transition herauskommt,
ist mit a.selection ein Wahheitswert definiert. Die guard-Funktion prüft alle diese
Wahrheitswerte (mit einer logischen Und-Verknüpfung) ab.
4. Analyse des Objektflusses
Mit der oben definierten Semantik können wir jetzt alle Standard-Bewertungs- und
Verifikationstechniken der Petri-Netze für die UML 2.0 Aktivitätsdiagramme übernehmen.
Angenommen, A ist eine Aktivität, die durch die oben genannte Semantik zu einem CPN
N abgebildet wird ([A]=N).
4.1 Verifikation
Eine Ablaufverfolgung (trace) ist eine Hilfsmittel für das Testen oder die Überprüfung
eines Designs. Eine Ablaufverfolgung kann sich in einer Ablaufverfolgung verwandeln,
wenn man die „internen“ Funktionen aux , fork and join . Die Aktivität in der Abbildung 10
ist jetzt in der Abbildung 15 als CPN dargestellt.
16
(id,false,false,false,false)
id
1´1
iN
INT
Receive_order
p1
ORDER
order
order
fill_order
fill(order)
p2 ORDER
order
order
fork
order
ORDER
p5
p3
order
ship(order)
p4
Receive_payment
p7
join
#1 order
pay(order)
ORDER
order2
join(order,order2)
close_order
INT
aux
bill(order)
p6 ORDER
order
order
fN
order
Send_invoice
Ship_goods
ORDER
ORDER
p8
order
order
ORDER
Abbildung 15 Das Petri-Netze repräsentiert die Aktivität und den Objekttyp, die in
Abbildung 10 definiert sind.
Hier ist eine Anfangsmarke nötig. Wir nehmen einfach eine Marke mit Wert 1 als
Anfangsmarke. Angenommen eine Anfangmarke (Initialmarkierung) für die Stelle
repräsentiert einen Startknoten. In Abbildung 15, die Anfangsmarke ist 1’1.
Wir benutzen CPN Toolset als Simulator und CPNs mit standard ML Ausdruck wird als
unsere Semantik Domäne ausgewählt. Der Text für Abbildung 15 benutzt Standard ML
code. (ORDER ist ein Benutzer definiertes Typ.)
Color ORDER=product INT *BOOL*BOOL*BOOL*BOOL
Var id:INT;
Var order,order2:ORDER;
fun init()=(1,flase,flase,flase,flase);
fun fill(o1:ORDER):ORDER=(#1o1,true,#3 o1,#4 o1,#5 o1)
fun bill(o1:ORDER):ORDER=(#1 o1,#2 o1,true,#4 o1,#5 o1)
fun pay(o1:ORDER):ORDER=(#1 o1,#2 o1,#3 o1,true,#5 o1)
fun ship(o1:ORDER):ORDER=(#1 o1,#2 o1,#3 o1,#4 o1,true)
fun join(o1:ORDER, o2:ORDER):ORDER=(#1 o1,#2 o1 orelse #2 o2, #3 o1 orelse
#3 o2 ,#4 o1 orelse #4 o2 ,#4 o1 orelse #4 o2);
ORDER ist ein vom Benutzer definierter Typ, der aus 5 Elemente besteht. Das erste ist
„
„
„
„
„
„
„
„
„
17
eine integer Typ. Es bezeichnet die Nummer einer Bestellung. Das zweite Elemente
bezeichnet, ob die Bestellung akzeptiert ist. Das dritte Elemente bezeichnet, ob die
Rechnung zum Kunde geschickt ist. Wenn der Wert True ist, ist sie schon geschickt
worden. Wenn das vierte Elemente True ist, heißt das, dass der Kunde schon bezahlt hat,
sonst bleibt das Element false.
Aus dem fünften Element kann man ersehen, ob die Waren schon zum Kunde geschickt
wurden.
Duch die Funktion join werden zwei Variable zusammengesetzt. Nur wenn für beide
Aktivität fertig ist, bekommen wir als Resultat (1,true,true,true,true), und der Prozess kann
jetzt enden.
1´1
(id,false,false,false,false)
id
iN
INT
Receive_order
p1
ORDER
order
order
fill_order
fill(order)
p2 ORDER
order
order
fork
order
ORDER
p3
p5
order
ship(order)
p4
Receive_payment
p7
join
#1 order
pay(order)
ORDER
order2
join(order,order2)
close_order
INT
aux
bill(order)
p6 ORDER
order
order
fN
order
Send_invoice
Ship_goods
ORDER
ORDER
p8
order
order
ORDER
Abbildung 16 ein Schritt innenhalb eines Ablauf
In abb. 16 wird ein ausgewählter Ablauf des CPN aus Abb. 10 vorgestellt. In der linken
Spalte findet sich die Markierung der jeweiligen markierten Stelle, so bedeutet z.B.
<p2,<1,tt,ff,ff,ff>>, dass die Stelle p2 mit dem Objekt-Token ,<1,tt,ff,ff,ff> belegt ist.
Die zweite Spalte zeigt die schaltende Transition. Die dritte Spalte gibt die
Variablenbelegung für die dabei verwendeten Funktionen wieder (z.B., für das Schalten
18
der Transition „fill-order“ wird die Variable o1 der Funktion fill mit dem Wert <1,tt,ff,ff,ff>
gebunden).
Abbildung 17 Ein Ablauf des CPN.aus Abb. 16
(Die funktionale Programmiersprache Standard ML ist eine getypte Sprache, die einige
Unterstützung bei der Programmierung bietet:
1. Typsystem: Automatische Herleitung von Typen bei der Übersetzung, Deklaration von
freien Datentypen, Abstrakte Datentypen; Datentyp kann sein; Atomar (integers, reals,
strings, booleans und enumerations) oder strukturiert (products, records, unions, lists und
subsets).
2. Funktionen: Höherstufige Funktionen, Funktionsdefinition durch Fallunterscheidung
nach Mustern des Arguments
3.Imperative Konstrukte: referenzierbare Objekte (Zeiger), Schleifenkonstrukte
4. Modulsystem: Verpackung von Typen, Objekten und Funktionen in ,,Strukturen''
Zusammensetzung von Strukturen zu größeren Moduln durch ,,Funktoren'' ,
Spezifikation und Überprüfung von Schnittstellen zwischen Moduln
5. Neuübersetzung nach Programmänderungen: Automatische Abhängigkeitsanalyse
zwischen Moduln , Automatische Neuübersetzung nur der notwendigen Module )
4.2 Analyse
Es praktisch wenn man sich entscheiden kann, ob ein bestimmter Zustand erreicht
werden kann.So kann z.B. die Frage „Wird der Endzustand unter allen Bedingungen
erreicht?“ folgendermaßen formuliert werden:
19
∀m ∈ RN ( m) : m ∈ RN (m)
m ist die Anfangsmarkierung von N (CPN)
m ist die Endmarkierung von N (CPN)
R N (m)
bedeutet die gesamte Menge von Markierung von N(CPN), die erreicht werden
können.
Als weitere interessante Frage kann die Feststellung der Abwesenheit von Deadlocks für
CPNs folgendermaßen formuliert werden:
t
∀m ∈ RN ( m) : ∃t ∈ TN : m ⎯
⎯→
⎯→ eine Petri-Netz-Notation, die bedeutet, dass die Transition t unter der
Dabei ist m ⎯
t
Markierung m aktiviert ist.
Diese Frage “wenn eine Bestellung ausgeführt ist, wird die bezügliche Waren schließlich
auch geliefert? “kann so fomuliert werden:
fill _ order
∀m ∈ RN ( m) : ∃t ∈ TN : m ⎯⎯
⎯⎯→ ⇒
goods 0 rder
∃m' ∈ RN ( m) : m' ⎯ship
⎯−⎯
⎯⎯
⎯→
Diese Beispiele zeigen, dass es nicht schwer ist, wichtige Fragestellungen an das System
in die Sprache der Petri-Netze umzusetzen und damit einer formalen Analyse zugänglich
zu machen.
4.3 Quantitative Analyse
In unserem Beispiel ist es nicht hinreichend, zu überprüfen, ob die Waren schlussendlich
geschickt worden sind, sondern es sollten auch vorgegebene Zeitbegrenzungen (time
bound) eingehalten werden. Für viele Anwendungen ist es außerdem praktisch, z.B. die
Anzahl der Bestellungen in dem System in eine gegebene Zeit zu bestimmen. Für solche
Anfragen werden oft stochastische Petri-Netze verwendet. Für UML 1.x gibt es zu diesem
Thema bereits viele Arbeiten, die sich mit den entsprechenden Problemen befassen; auch
für UML 2.0 sind entsprechende Lösungen zu erwarten.
20
5
Zusammenfassung
In dieser Präsentation wurden Unterschiede zwischen UML1.x und UML 2.0 diskutiert.
Die Begriffe Petri-Netze und gefärbte Petri-Netze sind dargestellt worden. Weil
Aktivitätsdiagramme und Petri-Netze verwandt sind, ist es nicht schwer ein
Aktivitätsdiagramm in ein Petri-Netz umzusetzen. Die Semantische Abbildung von
Aktivitätsdiagrammen auf Petri-Netze wurde diskutiert. Anhand eines Beispiels, wurde
gezeigt wie man ein UML Aktivitätsdiagramm in ein CPN umsetzen kann.
[1]Harald Störrle: Semantics and Verification of Data Flow in UML 2.0 Activities. Institute
für informatik, Ludwig-Maximilians-Universität München, Germany
[2]B. Oesterreich:
Die UML2.0 Kurzreferenz für die Praxis 2004. Oldenbourg
Wissenschaftsverlag GmbH
[3]Marc Born, Eckhardt Holz, Olaf Kath:
Softwareentwicklung mit UML2.0.
Addison-Wesley ,2004
[4]Cris Kobryn, Grady Booch, Ivar Jacobson and Jim Rumbaugh: UML DistilledThird
Edition a Brief Guide to the Standard Object Modelling Language.
Addison-Wesley
[5] K. Jensen G. Rozenberg:
High–level Petri Nets. Theory and Application.
Springer-Verlag Berlin Heidelberg, 1991
[6] Roberto W.S. Rodrigues: Formalising UML Activity Diagrams using Finite State
Processes. Imperial College, 180, Queen’s Gate SW7 2BZ, London UK.
[7] CP-Netze und Werkzeuge
http://www.daimi.au.dk/CPnets/
http://www.ento.vt.edu/~sharov/PopEcol/lec1/petrinet.html
PSUML(UML Diagrammer)
[8] UML
http://www.oose.de/
[9] UML 2.0 Superstructure Specification.
21