eine formale beschreibung der dynamischen semantik von … · 2019. 12. 4. ·...
TRANSCRIPT
-
Eine formale Beschreibung der dynamischen Semantik von ESSENCE
Masterarbeit
im
Studiengang Angewandte Informatik
am Institut für Informatik und Wirtschaftsinformatik
der Universität Duisburg-Essen
Sebastian Holtappels
2231384
Essen, 24. November 2014
Betreuer: Michael Striewe
Erstgutachter: Prof. Dr. Michael Goedicke
Zweitgutachter: Prof. Dr. Klaus Pohl
-
Eidesstattliche Erklärung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE I
Eidesstattliche Erklärung
Hiermit versichere ich, dass ich die vorliegende Arbeit ohne Hilfe Dritter und nur mit
den angegebenen Quellen und Hilfsmitteln angefertigt habe. Ich habe alle Stellen, die
ich aus den Quellen wörtlich oder inhaltlich entnommen habe, als solche kenntlich
gemacht. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbe-
hörde vorgelegen.
Essen, den 24.11.2014
_____________________________________
Sebastian Holtappels
-
Zusammenfassung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE II
Zusammenfassung
In dieser Arbeit wird die dynamische Semantik von Essence mit Hilfe von Graph-
Transformation formal beschrieben. Durch diese formale Beschreibung ergeben sich
Anwendungsmöglichkeiten, die für Anwender und Ersteller des Essence-Standards
(OMG 2014) nützlich sein können. Eine Anwendungsmöglichkeit ist die automatische
Generierung von Modellierungswerkzeugen. Diese Arbeit richtet sich an die beteilig-
ten Personen und Institutionen der SEMAT-Initiative sowie an Personen und Institu-
tionen, die die im Essence-Standard (OMG 2014) beschriebene Sprache einsetzen wol-
len oder bereits einsetzen. Die Ziele dieser Arbeit sind die Entwicklung von generi-
schen und nicht-generischen Graph-Transformationsregeln für die dynamische Sem-
antik der Essence-Sprache sowie die Definition von Heuristiken für die Ableitung wei-
terer Regeln. Ferner stellt auch die Beschreibung von Anwendungsmöglichkeiten, die
durch die Erstellung der Regeln entstehen, ein weiteres Ziel dieser Arbeit dar. Das
Ergebnis dieser Arbeit stellt eine generische, auf Graph-Transformationsregeln beru-
hende, formale Beschreibung der dynamischen Semantik sowie Regeln für die Be-
schreibung des Essence-Kernels und der Entwicklungspraxis Scrum dar. Auch werden
Anwendungsmöglichkeiten dieser Beschreibung und Heuristiken für die Definition
weiterer Regeln beschrieben.
Abstract
The topic of this thesis is a formal description of the dynamic semantics of Essence
(OMG 2014) through graph transformation rules. The formal description with graph
transformation enables new applications for users and creators of Essence (OMG
2014). One possible application is the automatic generation of modeling tools. This
work is aimed at persons and institutions participating in the SEMAT initiative as well
as those persons or institutions that use or want to use the Essence language. The ob-
jectives of this thesis are the development of generic and non-generic graph transfor-
mation rules for the dynamic semantics of the Essence language, as well as the descrip-
tion of heuristics for defining additional rules and the description of applications that
arise from the creation of these rules. The result of this thesis is a generic and formal
description of the dynamic semantics based on graph transformation rules and addi-
tional graph transformation rules for the description of the Essence kernel and of the
development practice Scrum. Further results are the description of possible applica-
tions and heuristics for the definition of additional rules.
-
Abbildungsverzeichnis
Eine formale Beschreibung der dynamischen Semantik von ESSENCE III
Abbildungsverzeichnis
Abbildung 1: Schichtenarchitektur von Essence ______________________________________ 3
Abbildung 2: Alphas des Essence-Kernels ___________________________________________ 5
Abbildung 3: „Activity Spaces“ des Kernels _________________________________________ 6
Abbildung 4: Die Competencies des Kernels _________________________________________ 6
Abbildung 5: Übersicht über die Elemente der Essence-Sprache ________________________ 7
Abbildung 6: Typ-Graph _________________________________________________________ 16
Abbildung 7: Beispiel mit und ohne help_StateTransition-Hilfsknoten _________________ 17
Abbildung 8: Beispiel „Alpha Association“ und help_InstanceAssociation-Hilfsknoten ___ 17
Abbildung 9: Beispiel eines Instanz-Graphen _______________________________________ 18
Abbildung 10: RHS von Regel 104 (groß) __________________________________________ 122
Abbildung 11: RHS von Regel 101 (groß) __________________________________________ 123
Abbildung 12: RHS von Regel 102 (groß) __________________________________________ 124
Abbildung 13: RHS von Regel 103 (groß) __________________________________________ 125
Abbildung 14: RHS von Regel 105 (groß) __________________________________________ 126
Abbildung 15: RHS von Regel 106 (groß) __________________________________________ 127
Abbildung 16: LHS von Regel 107 (groß) __________________________________________ 128
Abbildung 17: NAC 1 von Regel 107 (groß) ________________________________________ 128
Abbildung 18: RHS von Regel 107 (groß) __________________________________________ 129
Abbildung 19: LHS von Regel 108 (groß) __________________________________________ 129
Abbildung 20: RHS von Regel 108 (groß) __________________________________________ 130
Abbildung 21: Typ-Graph (groß) _________________________________________________ 131
Abbildung 22: Beispiel eines Instanz-Graphen (groß) _______________________________ 132
-
Abkürzungs- und Akronymverzeichnis
Eine formale Beschreibung der dynamischen Semantik von ESSENCE IV
Abkürzungs- und Akronymverzeichnis
AC Attribute Conditions
Alpha „Abstract-Level Progress Health Attribute”
bzw. beziehungsweise
CD Compact Disc
LHS Left Hand Side
NAC Negative Application Condition
OMG Object Management Group
PAC Positive Application Condition
RHS Right Hand Side
SEMAT Software Engineering Methods and Theory
Sub-Alpha Subordinate Alpha
z. B. zum Beispiel
-
Inhaltsverzeichnis
Eine formale Beschreibung der dynamischen Semantik von ESSENCE V
Inhaltsverzeichnis
Eidesstattliche Erklärung ___________________________________________________ I
Zusammenfassung ________________________________________________________ II
Abstract _________________________________________________________________ II
Abbildungsverzeichnis ____________________________________________________ III
Abkürzungs- und Akronymverzeichnis _______________________________________ IV
Inhaltsverzeichnis ________________________________________________________ V
1 Einleitung ____________________________________________________________ 1 1.1 Motivation _______________________________________________________________ 1
1.2 Thema und Ziele der Arbeit ________________________________________________ 1
1.3 Gang der Arbeit __________________________________________________________ 2
2 Grundlegung __________________________________________________________ 3 2.1 Essence __________________________________________________________________ 3
2.1.1 Allgemeines ___________________________________________________________________ 3 2.1.2 Essence Kernel _________________________________________________________________ 4 2.1.3 Essence Language ______________________________________________________________ 7
2.2 Graph-Transformation ___________________________________________________ 11
3 Allgemeine Regeln der dynamischen Semantik ____________________________ 13 3.1 Vorgehen und Beschreibungsart ___________________________________________ 13
3.2 Typ-Graph für Essence ___________________________________________________ 15
3.3 Auflistung der Graph-Transformationsregeln _______________________________ 19
3.4 Regeln für die Erstellung des Kernels ______________________________________ 98
4 Ableitung von Regeln für Software-Entwicklungspraktiken _______________ 108 4.1 Auflistung der Graph-Transformationsregeln für SCRUM __________________ 108
4.2 Heuristiken zur Ableitung von weiteren Regeln ____________________________ 116
5 Anwendungsmöglichkeiten ____________________________________________ 118
6 Diskussion und Ausblick______________________________________________ 120
Anhang I: Vergrößerte Abbildungen von Graphen ____________________________ 122
Anhang II: Regelverzeichnis _______________________________________________ 133
Literaturverzeichnis ______________________________________________________ 137
-
Einleitung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 1/140
1 Einleitung
In dieser Einleitung werden die Motivation und das Thema dieser Arbeit beschrieben.
Ferner werden die Ziele, die Forschungsmethode und der Aufbau der Arbeit erläutert.
1.1 Motivation
Die „Software Engineering Method and Theory“-Initiative, kurz SEMAT-Initiative
versucht eine theoretische Basis für das „Software Engineering“ zu entwickeln. Hierzu
entwickeln die an der SEMAT-Initiative beteiligten Institutionen einen gemeinsamen
Kern vieler „Software Engineering“-Methoden, genannt Kernel. Darauf aufbauend
können Erweiterungen für spezifische Eigenschaften von bestimmten Methoden defi-
niert werden. Aufbauend auf der Arbeit der SEMAT-Initiative wurde der Essence-
Standard (OMG 2014) der „Object Management Group“ (OMG) entwickelt. (Johnson
et al. 2012, S. 94-95; Ng et al. 2013, S. 52; OMG 2014, S. 8)
Die im Essence-Standard (OMG 2014) beschriebene Sprache für die Beschreibung von
Software-Entwicklungsmethoden definiert unter anderem eine dynamische Semantik
(OMG 2014, S. 103-109). In dieser Arbeit soll diese dynamische Semantik mit Hilfe von
Graph-Transformationsregeln formal beschrieben werden. Zwar enthält der Essence-
Standard (OMG 2014) bereits eine formale Beschreibung der dynamischen Semantik,
jedoch eröffnet die Verwendung von Graph-Transformationsregeln neue Möglichkei-
ten (OMG 2014, S. 108-109). So kann z. B. die Vollständigkeit der Beschreibung gezeigt
oder Aussagen zu real durchgeführten Entwicklungsprozessen gemacht werden.
Diese Arbeit richtet sich an die beteiligten Institutionen und Personen der SEMAT-
Initiative sowie an Personen und Institutionen, die die im Essence-Standard (OMG
2014) beschriebene Sprache einsetzen wollen oder bereits einsetzen.
1.2 Thema und Ziele der Arbeit
Das Thema dieser Arbeit ist die formale Beschreibung der dynamischen Semantik der
Essence-Sprache durch Graph-Transformationsregeln sowie das Aufzeigen von An-
wendungsmöglichkeiten, die sich durch diese Beschreibung ergeben.
Es werden dabei zwei Arten von Regeln unterschieden: erstens Regeln, die für alle in
der Essence-Sprache beschriebenen Software-Entwicklungspraktiken gelten, zweitens
Regeln, die nur für eine bestimmte Software-Entwicklungspraxis gelten. Aufgrund der
Anlage dieser Arbeit werden die nicht generischen Regeln nur für eine bestimmte Soft-
ware-Entwicklungspraxis definiert und darauf aufbauend Heuristiken für das Vorge-
hen bei der Definition solcher Regeln beschrieben.
Die Anwendungsmöglichkeiten, die sich durch die formale Beschreibung durch
Graph-Transformation ergeben, werden in dieser Arbeit nur aufgezeigt. Es ist nicht
Gegenstand dieser Arbeit sämtliche dieser Möglichkeiten auch auszuführen.
-
Einleitung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 2/140
Folglich können für diese Arbeit die folgenden Ziele definiert werden:
Herausarbeitung generischer Graph-Transformationsregeln
Herausarbeitung von Graph-Transformationsregeln für eine spezifische Soft-
ware-Entwicklungspraxis
Entwickelung von Heuristiken zur Ableitung von Graph-Transformationsre-
geln für beliebige Software-Entwicklungspraktiken
Beschreibung von Anwendungsmöglichkeiten, die durch die formalisierte Se-
mantik entstehen
Da es sich um eine theoretische Arbeit handelt, wird zur Erreichung der Ziele vor al-
lem eine Literaturrecherche eingesetzt.
1.3 Gang der Arbeit
Den Rahmen dieser Ausarbeitung stellen die Kapitel 1 und 2 sowie Kapitel 6 dar. Auf
diese Einleitung (Kapitel 1) folgt in Kapitel 2 eine kurze Beschreibung der Grundlagen,
die für diese Arbeit relevant sind. Neben den Grundlagen der Graph-Transformation
umfasst dieses Kapitel eine Einführung in den Essence-Standard (OMG 2014). Dieses
Kapitel dient dazu, dass die Grundlagen, die für das Verständnis dieser Arbeit not-
wendig sind, allen Lesern bekannt sind, ohne dass umfassende Vorkenntnisse im Be-
reich Graph-Transformation oder Essence notwendig sind.
Kapitel 6 ist der inhaltliche Abschluss dieser Arbeit. Es beinhaltet eine Diskussion der
erzielten Ergebnisse und einen Ausblick.
In Kapitel 3 und 4 erfolgt die Ableitung der Graph-Transformationsregeln aus dem
Essence-Standard (OMG 2014). Diese Kapitel stellen den Hauptteil der Arbeit dar. In
Kapitel 3 werden die Regeln beschrieben, die für alle Software-Entwicklungspraktiken
gelten, die mit dem Essence-Standard (OMG 2014) beschrieben wurden. Zu Beginn
von Kapitel 3 wird ferner das Vorgehen zur Ableitung und Beschreibung der Regeln
vorgestellt.
Kapitel 4 beschreibt anhand einer ausgewählten Software-Entwicklungspraxis die
Graph-Transformationsregeln, die zusätzlich zu den in Kapitel 3 formulierten Regeln
notwendig sind. Anschließend erfolgt die Beschreibung von Heuristiken zur Formu-
lierung dieser Regeln für eine beliebige Software-Entwicklungspraxis.
Kapitel 5 befasst sich mit den Anwendungsmöglichkeiten, die durch die formale Be-
schreibung der Semantik durch Graph-Transformationsregeln entstehen.
-
Grundlegung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 3/140
2 Grundlegung
In diesem Kapitel werden die notwendigen Grundlagen für diese Arbeit erläutert. Es
erfolgt jeweils eine Erläuterung der relevanten Eigenschaften des Essence-Standards
(OMG 2014) und der Graph-Transformation.
2.1 Essence
Im Folgenden wird der Essence-Standard (OMG 2014) kurz beschrieben. Im Mittel-
punkt stehen hierbei die Beschreibung des Essence-Kernel und der Essence-Sprache.
2.1.1 Allgemeines
In diesem Abschnitt erfolgt eine allgemeine Einführung in den Essence-Standard
(OMG 2014). Neben dem Aufbau des Essence-Standards (OMG 2014) werden auch
Vorteile sowie die Verbindung zur SEMAT-Initiative beschrieben.
Der Essence-Standard (OMG 2014) ist ein Ergebnis der Arbeit der SEMAT-Initiative
und stellt einen Teil des Versuchs dar, eine allgemeine Theorie für „Software Engine-
ering“ zu entwickeln (Graziotin und Abrahamsson 2013, S. 1; Elvesæter et al. 2012, S.
279; OMG 2014, S. 8). Die Vorteile einer solchen allgemeinen Theorie für „Software
Engineering“ sollen unter anderem eine bessere Vorhersagbarkeit der Ergebnisse, die
bessere Vergleichbarkeit und die einfachere Auswahl von Programmiersprachen und
Entwicklungsmethoden für Software-Projekte sein (Johnson et al. 2012, S. 94; OMG
2014, S. 8). Trotz unterschiedlicher Versuche gibt es bis heute keine allgemein aner-
kannte Theorie für das „Software Engineering“ (Johnson et al. 2012, S. 95-96; Graziotin
und Abrahamsson 2013, S. 1).
Abbildung 1: Schichtenarchitektur von Essence
Quelle: OMG 2014, S. 9
Der Essence-Standard (OMG 2014) definiert einen Kernel, der die gemeinsame Schnitt-
menge aller Software-Entwicklungsmethoden umfassen soll, und eine Sprache für die
Beschreibung des Kernels und darauf aufbauender Software-Entwicklungsmethoden
und -praktiken. Abbildung 1 zeigt die Schichtenarchitektur von Essence sowie die Zu-
sammenhänge zwischen den einzelnen Schichten. Der Essence Kernel dient als Grund-
lage für alle Software-Entwicklungspraktiken, welche wiederum in Software-Entwick-
lungsmethoden zusammengefasst werden können. (OMG 2014, S. 1, 8-11)
-
Grundlegung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 4/140
Praktiken werden im Essence-Standard (OMG 2014) als wiederholbare, systematische
und überprüfbare Herangehensweise an bestimmte Aspekte des „Software Enginee-
ring“ verstanden. Eine Methode ist die Komposition beliebiger Praktiken und soll ne-
ben der reinen Beschreibung der Vorgehensweise auch die tägliche Arbeit der Ent-
wickler unterstützen. Der Essence-Kernel und die Essence-Sprache werden in Ab-
schnitt 2.1.2 und 2.1.3 beschrieben. (OMG 2014, S. 9)
Mithilfe von Essence sollen Methoden und Praktiken leichter vergleichbar sein (OMG
2014, S. 1, 8, 10). Auch unterstütze Essence Anwender bei der Implementierung neuer
Praktiken bzw. Methoden (Jacobson und Spence 2009; OMG 2014, S. 8). Ferner erleich-
tere Essence auch das Lernen neuer Methoden sowie bzw. dadurch auch den Einstieg
in ein neues berufliches Umfeld (Jacobson und Spence 2009). Des Weiteren ermögliche
Essence Erfahrungen aus vergangenen Projekten leichter auf neue Situationen zu
übertragen und somit Wissen besser zu nutzen (Jacobson und Spence 2009; Ng 2014,
S. 14). Diese Vorteile entständen durch die einheitliche Beschreibung der Praktiken
und Methoden durch die Essence-Sprache und die Definition eines gemeinsamen
Kernels (Jacobson und Spence 2009; Ng 2014, S. 14; OMG 2014, S. 8). Diese einheitliche
Basis vereinfache auch die Migration von einer Methode zu einer anderen oder den
Austausch von Praktiken (Jacobson et al. 2012, S. 10).
Einen weiteren Vorteil stelle die Trennung der Überwachung und Steuerung von Pro-
jekten von spezifischen Methoden dar, da die Überwachung und Steuerung lediglich
auf universellen Zuständen von sogenannten Alphas (siehe Abschnitt 2.1.2 und 2.1.3)
beruht (Ng und Huang 2013, S. 305; Ng 2014, S. 16; Péraire und Sedano 2014, S. 325).
Ferner könne Essence, da der Kernel keine praxis- oder methodenspezifischen Ele-
mente enthält, in Zusammenhang mit vielen bestehenden Methoden und Praktiken,
wie z. B. Scrum, dem Wasserfall-Modell oder Test-Driven-Development, eingesetzt
werden (Jacobson et al. 2012, S. 10).
2.1.2 Essence Kernel
Der Essence-Kernel, dessen Erstellung eine direkte Folge der Arbeit der SEMAT-Initi-
ative ist, soll eine gemeinsame Basis aller Software-Entwicklungspraktiken darstellen
(Jacobson et al. 2012, S. 1, 3-4; OMG 2014, S. 1, 10). Im Folgenden werden der Aufbau
und die Elemente des Kernels vorgestellt.
Der Kernel ist in drei „Areas of Concern“ unterteilt, die sich jeweils auf einen bestimm-
ten Aspekt von „Software Engineering“ beziehen. Die drei „Areas of Concern“ sind
Customer, Solution und Endeavour. In jedem dieser Bereiche gibt es Alphas (siehe
Abbildung 2), „Activity Spaces“ (siehe Abbildung 3) und Competencies (siehe Abbil-
dung 4), die Essence als essentielle Bestandteile des „Software Engineerings“ ansieht.
Der Kernel enthält keine weiteren Elemente der Sprache, da diese meist abhängig von
den eingesetzten Praktiken sind. (OMG 2014, S. 12–18)
-
Grundlegung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 5/140
Abbildung 2: Alphas des Essence-Kernels
Quelle: OMG 2014, S. 14
Der Kernel umfasst die folgenden Alphas (siehe Abbildung 2):
Opportunity: der eigentliche Grund sowie weitere Umstände, die die Entwick-
lung der Software nötig, möglich und sinnvoll machen (OMG 2014, S. 14)
Stakeholders: die Parteien, die durch das Software-System beeinflusst werden
oder die Entwicklung beeinflussen können (OMG 2014, S. 14)
Requirements: die Eigenschaften des zu erstellenden Software-Systems, die
notwendig sind, um die relevanten Bedürfnisse der Stakeholder zu befriedigen
(OMG 2014, S. 14)
Software System: das zu erstellende Software-System (OMG 2014, S. 14)
Team: die Gruppe von Menschen, die aktiv an der Entwicklung, Wartung, Aus-
lieferung oder dem Support des zu erstellenden Software-Systems beteiligt sind
(OMG 2014, S. 15)
Work: jede Tätigkeit des Teams zur Erstellung des Software-Systems (OMG
2014, S. 14-15)
Way of working: die Praktiken und Werkzeuge, die vom Team zur Erfüllung
ihrer Arbeit benutzt werden (OMG 2014, S. 15)
Die Alphas im Kernel haben jeweils eine vordefinierte Zustandsmenge, die für die
Überprüfung des Fortschritt und der Gesundheit eines Projektes verwendet werden
können (OMG 2014, S. 13). Für jeden Zustand eines Alphas gibt es eine ebenfalls vor-
definierte Checkliste zur Überprüfung, ob der Zustand bereits erreicht werden konnte
bzw. bei erneuter Überprüfung, ob die Bedingungen für diesen Zustand immer noch
erfüllt sind (OMG 2014, S. 13). Der Kernel gibt durch diese Zustände einen groben Plan
für das „Software Engineering“ vor, ohne zu definieren, wie man von einem Zustand
zum nächsten kommt (Ng 2014, S. 16; Jacobson et al. 2012, S. 4).
-
Grundlegung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 6/140
Abbildung 3: „Activity Spaces“ des Kernels
Quelle: OMG 2014, S. 15
Die „Activity Spaces“ erweitern den Kernel um eine aktivitätenbasierte Sicht. Eine ge-
naue Beschreibung der einzelnen „Activity Spaces“ kann in OMG (2014, S. 15-16) ge-
funden werden. Durch die vordefinierten „Activity Spaces“ legt der Kernel die essen-
tiellen Aufgaben fest, ohne zu definieren, wie diese erledigt werden sollten. (Elvesæter
et al. 2012, S. 283; OMG 2014, S. 15)
Abbildung 4: Die Competencies des Kernels
Quelle: OMG 2014, S. 17
-
Grundlegung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 7/140
Neben den Alphas und den „Activity Spaces” umfasst der Kernel auch Competencies
als eine Sicht auf die relevanten Fähigkeiten, die benötigt werden, um die erforderliche
Arbeit im „Software Engineering“ durchführen zu können (siehe Abbildung 4). Eine
genaue Beschreibung der einzelnen Competencies kann in OMG (2014, S. 17) gefunden
werden. Jede Competency im Kernel hat fünf „Level of Achievement“. Begonnen mit
dem Level Assists folgen Applies, Masters, Adapts und Innovates. (OMG 2014, S. 16-
18)
Praktiken fügen dem Kernel „Work Products“ und Activities hinzu. Es ist jedoch auch
möglich neue Alphas, „Activity Spaces“ und Competencies zu definieren. Folglich ist
für die Definition von Praktiken Wissen über den Essence-Kernel erforderlich. (Elves-
æter et al. 2013, S. 2, 4)
2.1.3 Essence Language
Der Essence-Standard (OMG 2014) definiert für die Essence-Sprache eine abstrakte,
eine graphische und eine textuelle Syntax sowie eine dynamische Semantik (OMG
2014, S. 1). Die Elemente dieser Sprache und die dynamische Semantik werden in die-
sem Abschnitt vorgestellt.
Abbildung 5: Übersicht über die Elemente der Essence-Sprache
Quelle: OMG 2014, S. 57
Abbildung 5 zeigt einen Überblick über die Elemente der Essence-Sprache sowie deren
Verbindungen. Neben den aus dem Kernel bekannten Elementen Alpha, „Alpha
State“, „Activity Space“ und Competency enthält die Sprache noch die Elemente
„Work Product“, Activity, Pattern und Resource (OMG 2014, S. 57). Im Folgenden wer-
den die in Abbildung 5 enthaltenen Elemente kurz beschrieben.
-
Grundlegung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 8/140
Alpha ist ein Akronym für „Abstract-Level Progress Health Attribute” (OMG 2014, S.
19, 75). Alphas sind Elemente, die im Software-Entwicklungsprozess verwaltet, er-
zeugt oder benutzt werden und relevant zur Erfassung des Fortschritts und der Ge-
sundheit des Vorhabens sind (OMG 2014, S. 12). NG (2014, S. 13, 16) beschreibt Alphas
als Darstellung der verschiedenen Dimensionen des „Software Engineering“.
Alphas haben fest definierte Zustände, auf Grundlage derer man wichtige Meilen-
steine definieren und den aktuellen Gesamtzustand der Unternehmung bestimmen
kann. Des Weiteren dienen Alphas als Input für „Activity Spaces“ und können in die-
sen aktualisiert oder auch erzeugt werden. (OMG 2014, S. 75)
Ein Alpha kann mit mehreren Sub-Alphas1 und „Work Products“ verbunden sein, de-
ren Zustände dann in die Bestimmung des Zustands des Alphas eingehen. Es besteht
jedoch keine direkte Beziehung zwischen dem Zustand der „superordinate Alphas“
und der Sub-Alphas. (OMG 2014, S. 75-76)
Ein „Alpha State“ ist ein definierter Zustand eines Alphas, dessen Erreichen bzw.
Nicht-Erreichen anhand von definierten Checkpoints überprüft wird. Checkpoints
sind Bedingungen bzw. Aussagen, die wahr oder falsch sein können. Diese Check-
points formen für jeden „Alpha State“ eine überprüfbare Checkliste, auf deren Grund-
lage das Erreichen bzw. Nicht-Erreichen eines Zustands festgestellt werden kann.
(OMG 2014, S. 62, 78)
Ein „Activity Space“ stellt eine abstrakte Beschreibung einer Aufgabe bzw. Problem-
stellung dar, die während der Entwicklung, Wartung und dem Support eines Soft-
ware-Systems vorkommen kann. Die Abschlusskriterien werden durch zu erreichende
„Alpha States“ definiert. (OMG 2014, S. 12, 84)
Eine Competency definiert die notwendigen Fähigkeiten, die erforderlich sind, um
bestimmte Aufgabentypen erledigen zu können. Competencies haben definierbare Le-
vel, die für ein konkretes Teammitglied festlegen, wie fähig er in der jeweiligen Com-
petency ist. (OMG 2014, S. 87)
Ein „Work Product“ ist eine konkrete Repräsentation eines Alphas aus einer bestimm-
ten Sicht. Mögliche „Work Products“ sind Modelle, Spezifikationen oder weitere Ar-
ten von Artefakten. „Work Products“ können sowohl als Input für einen Software-
Entwicklungsprozess dienen, als auch in diesem erstellt, vernichtet, benutzt oder ver-
ändert werden. (OMG 2014, S. 79)
Um den Detailgrad eines „Work Products“ zu beschreiben, werden in der Essence-
Sprache „Level of Detail“ verwendet. Diese sind ähnlich konstruiert wie „Alpha Sta-
tes“. Damit kann festgehalten werden, ob es sich z. B. um eine Skizze der System-Ar-
chitektur oder um ein formales Modell dieser handelt. Die Bestimmung des „Level of
Detail“ erfolgt ebenfalls über definierbare Checklisten. (OMG 2014, S. 77)
Die Verbindung eines Alphas mit einem „Work Product“ erfolgt über ein „Work Pro-
duct Manifest”. Diese geben unter anderem an, wie viele Instanzen des „Work Pro-
ducts“ mit dem referenzierten Alpha verbunden werden können. (OMG 2014, S. 79)
1 Dient als Ausdruck, dass das (Sub-)Alpha einem anderen Alpha, dem „superordinate Alpha, untergeordnet ist
-
Grundlegung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 9/140
Eine Activity definiert eine bestimmte Aufgabe, die die Umsetzung eines Teils von
einem oder eines vollständigen „Activity Spaces“ darstellt. Ferner definiert jede Acti-
vity, unter welchen Bedingungen diese Aufgabe begonnen werden kann bzw. abge-
schlossen ist. Die benötigten Fähigkeiten zur Durchführung der Aufgabe werden
durch die benötigten „Level of Achievements“ in den relevanten Competencies fest-
gelegt. Des Weiteren kann eine Activity verschiedene Approaches definieren, die fest-
legen, wie eine Activity durchgeführt werden soll. (OMG 2014, S. 80, 82-84)
Eine Activity kann Actions vorschlagen, die jedoch keinen direkten Bezug zur Erfül-
lung der Abschlusskriterien besitzen müssen. Eine Action ist ein Arbeitsschritt oder
wenige Arbeitsschritte in einer Activity mit Bezug zu einem bestimmten „Work Pro-
duct“. Die durchgeführten Actions können das Erstellen, Lesen, Aktualisieren oder
Löschen eines „Work Products“ sein. (OMG 2014, S. 81-82)
Pattern können zur Benennung von Strukturen, die aus Elementen der Essence-Spra-
che bestehen, verwendet werden. Eine mögliche Verwendung wäre die Definition ei-
ner Rolle mit Referenzen auf die benötigten Kompetenzen, auszuführende Aktivitäten
und andere relevante Elemente. Auch Vorbedingungen können mithilfe von Pattern
modelliert werden. (OMG 2014, S. 69)
Eine Resource stellt eine Referenz auf Inhalte oder Informationen außerhalb des Es-
sence-Modells dar. Das dient vor allem dazu, die Inhalte oder Informationen wie z. B.
Templates nicht direkt in das Essence-Modell übernehmen zu müssen, jedoch trotz-
dem zentral verwalten zu können. (OMG 2014, S. 72-73)
Die Elemente der Essence-Sprache werden benutzt, um alle weiteren Schichten von
Essence (siehe Abbildung 1), also Methoden, Praktiken und den Kernel, zu beschrei-
ben. Der Fokus im Essence-Standard (OMG 2014) liegt dabei auf der Definition der
konkreten Syntax (textuell und graphisch), um eine leicht verständliche Sprache zu
erzeugen. Ergänzend zu dieser statischen Grundlage umfasst die Essence-Sprache
auch eine kompakte dynamische Semantik. (OMG 2014, S. 10-11)
Zum Verständnis der dynamischen Semantik und den in Kapitel 3 und 4 präsentierten
Graph-Transformationsregeln ist eine kurze Erklärung der Meta-Ebenen, die im Es-
sence-Standard (OMG 2014) benutzt werden, notwendig. Die Metamodellierung im
Essence-Standard (OMG 2014) basiert auf der OMG Meta Object Facility (OMG 2013)
(OMG 2014, S. 55). Von den im Essence-Standard (OMG 2014) beschriebenen vier
Meta-Ebenen sind drei zum Verständnis dieser Arbeit relevant:
In der Meta-Ebene „Level 2“ werden die Konzepte der Sprache wie z. B. Alpha
beschrieben (OMG 2014, S. 55).
In der Meta-Ebene „Level 1“ werden die Elemente des Kernels oder einer Prac-
tice wie z. B. das Work-Alpha des Kernels beschrieben (OMG 2014, S. 55).
In der Meta-Ebene „Level 0“ werden die konkreten Instanzen, die während ei-
ner Unternehmung erstellt werden, beschrieben (OMG 2014, S. 55).
-
Grundlegung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 10/140
Im Essence-Standard (OMG 2014) wird dabei die Sprachregelung benutzt, dass ein
Konzept X der Ebene „Level 2“ auf „Level 1“ mit my_X und auf „Level 0“ mit
my_X_instance bezeichnet wird (OMG 2014, S. 104). Diese Sprachregelung wird auch
in dieser Arbeit eingehalten.
Für jede Unternehmung wird eine Kopie der Modelle der Meta-Ebene „Level 1“, also
der verwendeten Methode, der Praktiken und des Kernels, erstellt. Alle Änderungen
an den Praktiken oder an der Methode werden nur in dieser Kopie durchgeführt. Für
die Kapitel 3 und 4 wird das Vorhandensein dieser Kopie vorausgesetzt, ohne dass die
Erstellung dieser Kopie explizit modelliert wird. (OMG 2014, S. 106)
Die dynamische Semantik befasst sich mit der Erstellung des „Level 0“-Modells, der
Verfolgung und Bestimmung des Zustands der Unternehmung und der Ableitung von
Hilfestellung basierend auf dem aktuellen Modell (OMG 2014, S. 106). Im Folgenden
werden diese drei Bereiche der dynamischen Semantik genauer vorgestellt.
Erstellung und Aktualisierung des „Level 0“-Modells
Die Erstellung der Instanzen erfolgt, sobald diese für die Unternehmung benötigt wer-
den, was auch direkt am Anfang der Unternehmung der Fall sein kann. Die Grundla-
gen für die Instanziierung sind die Beschreibungen der verwendeten Praktiken und
vor allem die „Work Product Manifests“. Es ist jedoch auch möglich, dass die Prakti-
ken während der Unternehmung teilweise angepasst oder auch vollständig geändert
werden. (OMG 2014, S. 106)
Verfolgung und Bestimmung des Zustands der Unternehmung
Wie bereits erwähnt ergibt sich der Zustand der Unternehmung aus den Zuständen
der konkreten Alpha-Instanzen (OMG 2014, S. 106). Die Bestimmung des Zustands
einer Alpha-Instanz erfolgt dabei wie folgt:
1. Überprüfe für jeden Zustand alle Checkpoints, die mit ihm verbunden sind, auf
wahr oder falsch (OMG 2014, S. 106).
2. Der Zustand, bei dem alle Checkpoints erfüllt sind und der keine ausgehende
Kante zu einem Zustand hat, bei dem ebenfalls alle Checkpoints erfüllt sind, ist
der aktuelle Zustand des Alphas (OMG 2014, S. 107).
Die Ableitung des aktuellen „Level of Detail“ für die „Work Product“-Instanzen er-
folgt auf dieselbe Weise mit dem Unterschied, dass hier nur ein Checkpoint erfüllt sein
muss, damit das „Level of Detail“ als erfüllt gilt (OMG 2014, S. 62, 109).
Ableitung von Hilfestellung
Die Hilfestellung, die durch die dynamische Semantik bereitgestellt werden soll, kann
als die Erstellung einer To-do-Liste verstanden werden, die angibt, welche Activities
ausgeführt werden müssen, um vom aktuellen Zustand in einen gewünschten Folge-
zustand zu gelangen. Betrachtet werden dabei konkrete Alpha-Instanzen bzw. deren
aktueller und gewünschter Zustand. Für diese werden dann Instanzen der notwendi-
gen Activities angelegt, deren Abschlussbedingungen dem gewünschtem Zustand
entsprechen, also Instanzen jener Activities, die die Alpha-Instanz von dem aktuellen
in den gewünschten Zustand überführen. (OMG 2014, S. 103, 107-108)
-
Grundlegung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 11/140
2.2 Graph-Transformation
Dieser Abschnitt stellt die relevanten Aspekte von Graph-Transformation dar. Auch
wird herausgestellt, dass Graphen und Graph-Transformation ein bewährter Ansatz
für die Erfüllung der Ziele dieser Arbeit sind.
Graph-Transformationen sind lokale Manipulationen eines Graphen, also Manipula-
tionen eines Teilgraphen, die keine Auswirkung auf übrigen des Graphen haben. Der
zu verändernde Teilgraph sowie die durchzuführenden Änderungen werden dabei
durch Graph-Transformationsregeln beschrieben. (Ehrig und Löwe 1991, S. 689; Kre-
owski et al. 2006, S. 234; Kuske 2001, S. 241)
Graph-Transformationsregeln bestehen im Allgemeinen aus zwei Graphen: einem
Graphen, der die Ausgangssituation als einen Teilgraph des betrachteten Graphen be-
schreibt, und einem Graphen, der den Zielzustand dieses Teilgraphen nach der Durch-
führung der Transformation darstellt. Der Graph für die Ausgangsituation wird in den
meisten Fällen als „linke Seite“, im Englischen oft „Left Hand Side“ (LHS), und der
Graph für den Zielzustand der Transformation als „rechte Seite“, im Englischen oft
„Right Hand Side“ (RHS), der Regel bezeichnet. In dieser Arbeit werden die Abkür-
zungen LHS und RHS zur Benennung eingesetzt. (Bardohl et al. 1999, S. 120–121;
Kuske 2001, S. 244; Toffetti und Pezzè 2013, S. 209)
Zusätzlich zu den LHS- und RHS-Graphen wird teilweise noch ein Klebegraph als
weiterer Bestandteil einer Regel genannt. Dieser enthält alle Elemente, die durch die
Regelanwendung nicht verändert werden. Normalerweise wird dieser Klebegraph je-
doch nicht mitangegeben. (Kuske 2001, S. 244; Löwe 1990, S. 9)
Die Anwendung einer Graph-Transformationsregel auf einen Graphen G erfolgt in
drei Schritten. Zunächst wird ein Teilgraph von G gesucht, der der LHS der gewünsch-
ten Regel entspricht. Ist dieser gefunden werden alle Elemente aus diesem Teilgraphen
von G entfernt, die im LHS-Graphen aber nicht im RHS-Graphen vorkommen. Ab-
schließend werden die Elemente in G eingefügt, die im RHS-Graphen aber nicht im
LHS-Graphen vorkommen. Vereinfacht gesagt wird ein Teilgraph, der dem LHS-Gra-
phen entspricht, durch den RHS-Graphen ersetzt. (Andries et al. 1999, S. 5–6; Heckel
2006, S. 192; Toffetti und Pezzè 2013, S. 209)
Um zusätzliche Bedingungen für die Ausführung einer Graph-Transformationsregel
anzugeben, kann die LHS um beliebig viele Graphen erweitert werden. Diese werden
als „Application Conditions“ bezeichnet und können sich auch auf den Kontext des
von der Regel erfassten Teilgraphen beziehen. Je nachdem, ob die Existenz bzw. Nicht-
Existenz von Teilgraphen geprüft werden soll, unterscheidet man zwischen „Positive
Application Conditions“ (PAC) und „Negative Application Conditions“ (NAC). Eine
PAC beschreibt eine Struktur, die im Graphen G vorhanden sein muss, damit die Regel
angewendet werden kann. Entsprechend beschreibt eine NAC eine Struktur, die im
Graphen G nicht vorhanden sein darf, damit die Regel anwendbar ist. (Bottoni et al.
2000, S. 60; Ehrig et al. 1997, S. 278-279; Schürr 1997, S. 526; Toffetti und Pezzè 2013, S.
209)
-
Grundlegung
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 12/140
Neben Bedingungen, ob eine Regel ausgeführt werden darf, ist es für diese Ausarbei-
tung auch relevant festzulegen, welche Knoten- und Kanten-Typen existieren und wie
diese miteinander verbunden sind. Hierfür wird im Zusammenhang mit Graph-Trans-
formation meist ein weiterer Graph, der sogenannte Typ-Graph, verwendet. Dieser
legt auch die Kardinalitäten der Verbindungen fest. Mithilfe des Typ-Graphen ist es
auch möglich Attribute für die Kanten und Knoten zu definieren, die benutzt werden
können, um zusätzliche Informationen zu speichern. Diese Attribute können sowohl
als Bedingung für die Ausführung einer Regel benutzt werden als auch durch eine
Regel verändert werden. (Bardohl et al. 1999, S. 121; Heckel 2006, S. 190; Toffetti und
Pezzè 2013, S. 208-210)
Graph-Transformationen sind im Normalfall nicht-deterministisch, da die Auswahl
zwischen mehreren anwendbaren Regeln sowie die Auswahl des zu ersetzenden Teil-
graphen zufällig erfolgt. Aus diesem Grund können für Graph-Transformationsregeln
in manchen Software-Werkzeugen Informationen über die relative Ausführungsrei-
henfolge angegeben werden, z. B. indem bestimmten Regeln eine höhere Priorität zu-
gewiesen wird, oder indem definiert wird, dass nach der Ausführung einer Regel im-
mer oder in bestimmten Fällen eine andere Regel ausgeführt werden muss. (Andries
et al. 1999, S. 9; Ehrig et al. 1997, S. 279)
In der Literatur lassen sich einige Beispiele finden, bei denen Graph-Transformation
bzw. Graph-Grammatiken benutzt wurden, um die Syntax oder die Semantik von Mo-
dellen aus dem Bereich der Informatik zu beschreiben. So präsentiert KUSKE (2001)
eine formale Beschreibung eines Teils der operationalen Semantik von UML-Zu-
standsautomaten und MAGGIOLO-SCHETTINI UND PERON (1996) beschreiben die opera-
tionale Semantik von Statecharts mithilfe von Graph-Transformation. Auch BARDOHL
ET AL. (1999), BLOSTEIN UND SCHÜRR (1999) und BARESI UND HECKEL (2002) stellen fest,
dass Graph-Transformation geeignet ist, um die statische und dynamische Semantik
von visuellen Sprachen zu beschreiben.
Graph-Grammatiken bestehen aus einer Menge von zulässigen Graph-Transformatio-
nen sowie weiteren Elementen wie z. B. einem Startgraphen. Die Entwicklung von
Graph-Grammatiken erfolgte ursprünglich, da die Beschreibungsmächtigkeit der
Chomsky Grammatiken für nicht lineare Strukturen nicht ausreichend ist. (Bardohl et
al. 1999, S. 120–121; Drewes et al. 1997, S. 97; Heckel 2006, S. 188; Kreowski et al. 2006,
S. 237–238)
Die Verwendung von Graph-Grammatiken bzw. Graph-Transformation für die Be-
schreibung der Semantik bzw. Syntax ist sinnvoll, da viele Modellierungssprachen im
„Software Engineering“ wie z. B. „Entity Relationship“-Diagramme, die meisten
UML-Modelle und auch Petri Netze Graphen darstellen. Graph-Grammatiken bzw.
Graph-Transformationen bieten eine intuitive und vor allem visuelle Möglichkeit die
dynamischen Aspekte aber auch die Syntax dieser Modelle formal zu beschreiben. (Ba-
resi und Heckel 2002, S. 402, 410; Blostein und Schürr 1999, S. 212; Corradini et al. 1997,
S. 165; Ehrig und Löwe 1992, S. 2; Kreowski et al. 2006, S. 229)
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 13/140
3 Allgemeine Regeln der dynamischen Semantik
Dieses Kapitel beginnt mit der Vorstellung des Vorgehens zur Ableitung sowie der
Art der Beschreibung der definierten Regeln. Darauf folgt im Abschnitt 3.2 der Typ-
Graph für Essence und in 3.3 und 3.4 die Auflistung der allgemeinen Regeln.
3.1 Vorgehen und Beschreibungsart
Dieser Abschnitt beschreibt das Vorgehen zur Erstellung der Regeln sowie die Präsen-
tation der Regeln in dieser Arbeit. Allgemeine Heuristiken zur Ableitung weiterer Re-
geln werden in Abschnitt 4.2 beschrieben.
Als erster Schritt bei der Ableitung der Regeln wird der in Abschnitt 3.2 präsentierte
Typ-Graph definiert. Auf dessen Grundlage sowie durch schrittweise Ableitung aus
dem Standard werden dann die Regeln erst grob und anschließend detailliert formu-
liert. In dieser Ausarbeitung werden lediglich die finalen Regeln präsentiert.
Die Regeln wurden mit Hilfe von AGG erstellt. AGG ist ein Java-basiertes Software-
Werkzeug, das die Definition von Graph-Grammatiken unterstützt. Die in AGG ge-
zeichneten Graphen sind gerichtet, was dazu führt, dass bestimmte Regeln oder Teile
von Regeln in dieser Arbeit mehrfach definiert werden müssen. (Baresi und Heckel
2002, S. 422; Ermel et al. 1999)
Für die Präsentation dieser Regeln wird folgende Schablone2 verwendet:
Regel 0: Bezeichnung (AGG-Name)
LHS
RHS
AC 1
PAC 2
NAC 3
Textstelle/Beleg:
Erklärung und Diskussion:
Jeder Regel wird zur eindeutigen Identifikation eine Nummer zugewiesen. Die Num-
mern werden basierend auf der Reihenfolge der Regeln in dieser Arbeit vergeben und
stellen keine Rangfolge dar. Zusätzlich zur Nummerierung enthält die erste Zeile der
Schablone eine Bezeichnung für die Regel. Diese dient vor allem dem schnelleren Auf-
finden einer Regel über das Regelverzeichnis. Am Ende der Bezeichnung wird in
Klammern der Name der Regel in der beigefügten AGG-Datei genannt.
Darauf folgend wird die eigentliche Regel mit LHS und RHS sowie eventuelle ACs,
PACs und NACs dargestellt. ACs stellen „Attribute Conditions“ dar, also Bedingun-
gen über Attribute von Knoten oder Kanten, die erfüllt sein müssen, damit eine Regel
ausführbar ist. PAC und NAC entsprechen den Erklärungen aus Abschnitt 2.2.
2 Auch wenn diese Schablone eine Tabelle ist, wird sie nicht im Tabellenverzeichnis aufgeführt. Für die Regeln ist dieser Arbeit
ein Regelverzeichnis beigefügt. Auch werden die Abbildungen der Graphen nicht im Abbildungsverzeichnis aufgeführt.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 14/140
Für jede Bedingung (AC, PAC, NAC) wird eine eigene Zeile in die Tabelle eingefügt.
Die Bedingungen werden fortlaufend nach dem Schema „AC/PAC/NAC + Nummer“
nummeriert. Sollte eine Regel ACs, PACs und auch NACs umfassen, werden zuerst
alle ACs, dann PACs und darauf folgend alle NACs dargestellt.
Abschließend erfolgt eine Begründung und Erklärung der Regel. Dies erfolgt zunächst
durch die Angabe von Belegen in Form von Zitaten sowie Verweisen auf vorherige
Regeln und Inhalte anderer Kapitel dieser Arbeit. Auf diesen Beleg folgend erfolgt eine
Erklärung und Diskussion der Regel.
Im Allgemeinen werden nicht benötigte Zeilen der Schablone entfernt. Bei kleinen
LHS- und RHS-Graphen, werden diese in einer Zeile dargestellt.
Für die Priorisierungen der Regeln wurden fünf Stufen definiert. Eine Regel mit höhe-
rer Stufe muss vor allen Regeln niedrigerer Stufen angewendet werden, falls sie an-
wendbar ist. In AGG werden diese Stufen durch Prioritätswerte umgesetzt, die den
Stufen entsprechen. Im Folgenden werden die Prioritätsstufen kurz beschrieben:
Stufe 0, stellt den Standard für eine Regel dar, falls keine andere Stufe genannt
ist und wird folglich bei der Beschreibung einer Regel nicht erwähnt. Regeln
dieser Stufe werden normalerweise manuell angestoßen.
Stufe 1: Die Ausführung dieser Regeln sollte automatisch erfolgen, auf jeden
Fall aber vor den Regeln der Stufe 0. Es handelt sich um Regeln, die zusammen-
hängende Prozesse darstellen wie z. B. die Bestimmung des Zustands.
Stufe 2 und 3: Die Regeln von Stufe 2 und 3 dienen der Sicherstellung der Kon-
sistenz des Modells. Sie müssen vor allen anderen Regeln ausgeführt werden,
um Fehlentwicklungen zu verhindern (Ausnahmen stellen „Stufe 4“-Regeln
dar). Eine Regel ist auf Stufe 2, wenn sie in Zusammenhang mit einer weiteren
konsistenzerhaltenen Regel steht, die vor bzw. nach ihr angewendet werden
muss. Ein Beispiel stellen die Regeln zur automatischen Erzeugung von Sub-
Alphas dar (Regel 13, 15 und 16).
Stufe 4: Diese Stufe ist notwendig, da es beim Löschen von Elementen kurzzei-
tig zu inkonsistenten Situationen kommen kann, die nicht automatisch korri-
giert oder angemerkt werden sollten. Folglich sind Regeln, die sich mit dem
Löschen von Elementen befassen, höher zu priorisieren. Den Anstoß eines
Löschvorgangs stellt dabei immer eine Regel der Stufe 0 dar. Die Stufe 4 befasst
sich mit den notwendigen Schritten, um den Löschvorgang abzuschließen und
die Konsistenz des Modells wiederherzustellen.
AGG unterstützt die Unterscheidung zwischen manuellen und automatischen Regeln
nicht, die Prioritätswerte dienen also nur als eine Art Demonstration der Abläufe. Eine
Umsetzung der Regeln in ein Tool müsste diese Unterscheidung allerdings gewähr-
leisten.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 15/140
In 3.4 und 4.2 werden Regeln zur Beschreibung von Elementen des Kernels und der
Entwicklungspraxis SCRUM präsentiert. Diese stellen zwar keinen Teil der dynami-
schen Semantik des Essence-Standards (OMG 2014) dar, sind allerdings notwendige
Voraussetzung für den Einsatz der Regeln aus dem Abschnitt 3.3 und somit relevanter
Teil dieser Arbeit. Die Definition der Elemente erfolgt in folgender Reigenfolge:
1. Definition aller Alphas mit „Alpha States“ und Checkpoints; bei Sub-Alphas
wird auch die Beziehung zum „superordinate Alpha“ beschrieben.
2. Definition der „Work Products“ mit „Level of Detail und Checkpoints“
3. Definition der „Alpha Associations“
4. Definition der Activities
3.2 Typ-Graph für Essence
In diesem Abschnitt erfolgt die Präsentation sowie Beschreibung eines Typ-Graphen
für Essence, der die Grundlage für die Graph-Transformationsregeln darstellt.
Der in Abbildung 6 dargestellte Typ-Graph wurde auf der Grundlage des Essence-
Standards (OMG 2014) erstellt, insbesondere unter Verwendung von Abbildung 13
(OMG 2014, S. 57), Abbildung 21 (OMG 2014, S. 74) und Abbildung 23 (OMG 2014, S.
80) des Essence-Standards (OMG 2014). Zusätzlich wurden die Beschreibungen der
Elemente der Essence-Sprache (OMG 2014, S. 58-96) und die Beschreibung der dyna-
mischen Semantik (OMG 2014, S. 103-109) verwendet.
Der Typ-Graph enthält lediglich die Elemente der Essence-Sprache, die für die dyna-
mische Semantik unmittelbar benötigt werden. Er stellt somit keinen vollständigen
Typ-Graphen der Essence-Sprache dar. Wie in Abschnitt 2.1.3 erwähnt werden die
Knoten gemäß der Sprachregelung im Essence-Standard (OMG 2014) benannt. Zusätz-
lich zu dieser Sprachregelung wird für die Benennung von Hilfsknoten, also Knoten,
die keine direkte Entsprechung in der Essence-Sprache haben, die Regelung einge-
führt, dass diese mit einem Präfix help_ gekennzeichnet werden.
Es werden die folgenden fünf Kantentypen unterschieden:
BasicCon wird immer dann verwendet, wenn es keine spezialisierte Verbin-
dung gibt. Diese Verbindung verfügt über keine Attribute.
AlphaAssociation entspricht der „Alpha Association“ (OMG 2014, S. 76) und
stellt folglich die Verbindung zwischen zwei gleichwertigen Alphas dar. Es gibt
für beide Enden der Verbindung jeweils Attribute zur Angabe der Mindest-
und Maximalanzahl der erlaubten Verbindungen.
HierarchyCon beschreibt eine hierarchische Verbindung zwischen zwei Kno-
ten und entspricht dem „Work Produkt Manifest“ (OMG 2014, S. 79) und dem
„Alpha Containment“ (OMG 2014, S. 76-77). Es gibt Attribute zur Angabe der
Mindest- und Maximalanzahl der erlaubten Verbindungen.
HierarchyInstanceCon beschreibt eine hierarchische Verbindung auf Instanz-
Ebene. Diese Kante verfügt über das Attribut usedConnections, das die bereits
verwendeten Verbindungen erfasst.
InstanceCon beschreibt eine Kante zwischen einem Element auf der Meta-
Ebene „Level 1“ und einer Instanz dessen auf der Meta-Ebene „Level 0“.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 16/140
Abbildung 6: Typ-Graph
(siehe Abbildung 21 für eine größere Darstellung)
Die Knoten, die Elemente der Meta-Ebene „Level 1“ darstellen, besitzen alle das Attri-
but name. Die Knoten, die Elemente der Meta-Ebene „Level 0“ darstellen, besitzen alle
das Attribut instanceName. Zusätzlich zu diesen Attributen besitzen die Knoten vom
Typ my_State_instance und vom Typ my_LevelOfDetail_instance noch die Attribute
isActive, um den aktuellen „Alpha State“ oder das aktuelle „Level of Detail“ festzuhal-
ten, und isTargeted, um das anvisierte „Alpha State“ bzw. „Level of Detail“ festzule-
gen. Knoten vom Typ my_Checkpoint_instance besitzen das Attribut isChecked, mit
dem festgehalten wird, ob dieser Checkpoint erfüllt ist oder nicht.
Zusätzlich zu den von der Essence-Sprache definierten Knotentypen werden wenige
zusätzliche Knotentypen definiert. Es handelt sich hierbei um Hilfskonstrukte, die aus
technischen Gründen oder zur besseren Darstellbarkeit von Zusammenhängen einge-
führt werden.
Der Knotentyp help_StateTransition dient der Beschreibung der durch eine Activity
ausgelösten Zustandsveränderung bezogen auf genau ein Alpha. Diese exakte Defini-
tion der Auswirkung vereinfacht die Definition der Graph-Transformationsregeln, da
weniger Konsistenzprüfungen (in Form von NACs und PACs) durchgeführt werden
müssen. Abbildung 7 zeigt die Darstellung mit und ohne den Hilfsknoten. Hier wird
deutlich, dass im linken Teil der Abbildung der Rückgriff auf das Alpha notwendig
wird, während im rechten Teil der Abbildung die Verbindung über die Hilfsknoten
ausreicht, um zwei Zustände als zusammengehörig zu erkennen.
Der Knotentypen help_LevelOfDetailTransition ist in seiner Definition und Bedeu-
tung mit dem Knotentyp help_StateTransition äquivalent mit der Ausnahme, dass er
sich nicht auf „Alpha States“, sondern „Level of Details“ bezieht. Eine Activity kann
mit beliebig vielen Knoten der Typen help_LevelOfDetailTransition und help_StateT-
ransition verbunden sein, diese gehören jedoch immer genau zu einer Activity.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 17/140
Abbildung 7: Beispiel mit und ohne help_StateTransition-Hilfsknoten
Da die Auflösung der Viele-zu-Viele-Beziehungen zwischen zwei Alphas eine beson-
dere Herausforderung darstellt, wird für die Verbindung zwischen Alpha-Instanzen
auf Hilfsknoten zurückgegriffen. Der Knotentyp help_InstanceAssociation dient als
Zähler für die Verbindungen einer bestimmten Alpha-Instanz in Bezug auf eine be-
stimmte „Alpha Association“. Abbildung 8 stellt dieses Prinzip grafisch dar. Erkenn-
bar ist, dass für jede Instanz und jede „Alpha Association“ ein eigener Hilfsknoten
benötigt wird. Auch wird dargestellt, dass der Zähler im Hilfsknoten nur die Verbin-
dungen zählt, an der die verbundene Instanz beteiligt ist.
Abbildung 8: Beispiel „Alpha Association“ und help_InstanceAssociation-Hilfsknoten
Der help_InstanceAssociation-Knotentyp ist notwendig, da mit Hilfe von Graph-
Transformationsregeln nur Aussagen über eine feste Anzahl von Kanten gemachten
werden können (siehe 2.2). Folglich ist ein Zähler notwendig, der die Anzahl der Kan-
ten nachverfolgt und zur Einhaltung der Minimal- und Maximalanzahl benutzt wer-
den kann. Da die Instanzen eines Alphas allerdings unabhängig voneinander mit den
Instanzen anderer Alphas in Verbindung stehen können, ist ein globaler Zähler für
alle Instanzen eines Alphas nicht möglich. Folglich ergibt sich als eine Möglichkeit die
hier verwendete Lösung, die eine relativ simple Definition der notwendigen Graph-
Transformationsregeln ermöglicht.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 18/140
Der Knotentyp help_GuidanceCursor ist ein Hilfskonstrukt, das bei der Ableitung der
Hilfestellung in Form von Activity-Instanzen erzeugt und am Ende des Vorgangs wie-
der entfernt wird. Der Knotentyp hat drei Boolean-Attribute, die die aktuelle Phase
des Vorgangs anzeigen. Zusätzlich verfügt dieser Knotentyp über das Attribut in-
stanceCounter, das die erzeugten Instanzen zählt, um sicherzustellen, dass keine über-
flüssige Instanz erhalten bleibt. Die Attribute und deren Zusammenspiel werden in
den entsprechenden Regeln näher erläutert. Dieser Knotentyp vereinfacht die Defini-
tion der Regeln und ermöglicht ein algorithmisches Vorgehen zur Ableitung der Hil-
festellung. Der genaue Zweck des Knotens wird durch die entsprechenden Regeln ver-
deutlicht.
In Abbildung 9 ist die Entwicklungspraxis Scrum als Instanz-Graph des Typ-Graphen
(siehe Abbildung 6) beschrieben. Der Graph beruht auf der Beschreibung von Scrum
im Essence-Standard (OMG 2014, S. 230-241) und dem „Scrum Guide“ von SCHWABER
und SUTHERLAND (2013). Auf die Darstellung der States der Kernel-Alphas (Work,
Team, „Software System“ und Requirements) wurde verzichtet. Auch wird auf die
Darstellung der Checkpoints und die Beschriftung bei Kanten des Typs BasicCon ver-
zichtet.
Abbildung 9: Beispiel eines Instanz-Graphen
(siehe Abbildung 22 für eine größere Darstellung)
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 19/140
3.3 Auflistung der Graph-Transformationsregeln
In diesem Kapitel erfolgt die Auflistung der allgemeinen Regeln für die dynamische
Semantik. Die Regeln lassen sich in folgende Gruppen einteilen:
Regel 1-61: Erstellung und Aktualisierung des „Level 0“-Modells
Regel 62-73: Bestimmung des Zustands der Unternehmung
Regel 74-99: Ableitung von Hilfestellung
Regel 1: Erzeugen von Alpha-Instanzen (Rule1)
LHS
RHS
NAC 1
Textstelle/Beleg:
Basierend auf der Beschreibung der Erstellung und Aktualisierung des „Level 0“-
Modells als Teil der dynamischen Semantik (OMG 2014, S. 106)
Erklärung und Diskussion:
Alpha-Instanzen werden erstellt, sobald sie in einer Unternehmung benötigt wer-
den. Diese Regel beschreibt die Instanziierung eines Alphas, solange es kein Sub-
Alpha ist. Der Name der Alpha-Instanz muss der Regel vor ihrer Anwendung über-
geben werden. Dies geschieht über den Input-Parameter inName. (OMG 2014, S. 106)
Die LHS der Regel zeigt, dass die Grundlage für die Instanziierung ein Alpha auf
der Meta-Ebene „Level 1“ darstellt. In der RHS wird dann eine neue Instanz von
diesem Alpha erzeugt. Dem Attribut instanceName wird der Wert des Parameter
inName zugewiesen. Zur eindeutigen Referenzierung wird die Instanz durch eine
InstanceCon-Kante mit dem Alpha verbunden. Die Notwendigkeit dieser Verbin-
dung zeigt sich in den folgenden Regeln.
In NAC 1 wird festgelegt, dass diese Regel nur anwendbar ist, wenn es sich bei dem
zu instanziierenden Alpha nicht um ein Sub-Alpha handelt. Für die Instanziierung
von Sub-Alphas wurden eigene Regeln definiert, da diese immer in Abhängigkeit
eines anderen Alphas instanziiert werden und hierbei Minimal- und Maximalanga-
ben einzuhalten sind.
Regel 2: Erzeugen von Verbindungen zwischen Alpha-Instanzen (Rule2)
LHS
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 20/140
RHS
NAC 1
NAC 2
NAC 3
NAC 4
NAC 5
NAC 6
Textstelle/Beleg:
Basierend auf der Beschreibung der Erstellung und Aktualisierung des „Level 0“-
Modells als Teil der dynamischen Semantik (OMG 2014, S. 106)
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 21/140
Erklärung und Diskussion:
Die in dieser Arbeit gewählte Lösung zur Umsetzung von Verbindungen zwischen
Alpha-Instanzen (siehe 3.2) führt zu vier möglichen Fällen bei der Erstellung einer
neuen Verbindung zwischen zwei Instanzen. Es wird hier davon ausgegangen, dass
eine Verbindung nur zwischen bestehenden und nicht auch zwischen einer beste-
henden und einer noch zu erstellenden Instanz erzeugt werden kann.
Im ersten Fall, der in dieser Regel betrachtet wird, besitzen beide Alpha-Instanzen
noch keine Verbindungen zu einer Instanz des anderen an der „Alpha Association“
beteiligten Alphas. In diesem Fall muss die gesamte notwendige Struktur mit er-
zeugt werden, jedoch ist eine Beachtung von Angaben für die Maximalanzahl noch
nicht notwendig. Dies setzt voraus, dass die Maximalanzahl nicht null sein kann. Im
Allgemeinen lässt sich null als Maximalanzahl jedoch semantisch wertvoller durch
die Nicht-Existenz einer Beziehung ausdrücken. Zusätzlich kann es in solchen Situ-
ation zu unauflöslichen Inkonsistenzen kommen, wenn die Minimalanzahl auf der
einen Seite größer ist als null und die Maximalanzahl auf der anderen Seite null.
Dies würde bedeuten, dass die Instanzen des einen Alphas Verbindungen zu Instan-
zen des anderen Alphas benötigen würden, die Instanzen des anderen Alphas aber
keine Verbindungen zulassen dürften. In dieser Arbeit wird daher angenommen,
dass eine Maximalanzahl 1 oder höher sein muss. Die Angabe einer Null an dieser
Stelle wird schlicht durch diese Regel nicht beachtet.
Die weiteren Fälle bei der Erstellung einer Verbindung zwischen zwei Alpha-Instan-
zen werden in den folgenden Regeln behandelt.
Die Ausgangssituation (LHS) für diese Regel stellen zwei über eine AlphaAssocia-
tion-Kante verbundene Alphas dar, die jeweils mindestens eine Instanz haben. Für
diese Instanzen wird anschließend jeweils ein help_InstanceAssociation-Knoten er-
zeugt, dessen Attribut counter den Wert 1 zugewiesen bekommt. Diese zwei Knoten
werden mit ihrem jeweiligen Alpha und miteinander verbunden.
NAC 1 und 2 legen fest, dass die zwei Instanzen noch nicht miteinander verbunden
sein dürfen. In NAC 3, 4, 5 und 6 wird festgelegt, dass die Instanzen auch keine
Verbindungen zu anderen Instanzen des Alphas am anderen Ende der AlphaAssoci-
ation-Kante haben dürfen. Die doppelte Überprüfung einer Bedingung erfolgt auf-
grund der gerichteten Kante zwischen den help_InstanceAssociation-Knoten.
Regel 3: Erzeugen von Verbindungen zwischen Alpha-Instanzen (Rule3)
LHS
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 22/140
RHS
AC 1: v < x ODER x = -1
NAC 2
NAC 3
NAC 4
NAC 5
NAC 6
NAC 7
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 23/140
NAC 8
NAC 9
Textstelle/Beleg:
Basierend auf der Beschreibung der Erstellung und Aktualisierung des „Level 0“-
Modells als Teil der dynamischen Semantik (OMG 2014, S. 106)
Erklärung und Diskussion:
In dieser Regel wird der zweite Fall beim Erstellen einer Verbindung zwischen zwei
Alpha-Instanzen dargestellt. In diesem Fall besitzt die Instanz des Alphas am An-
fang der AlphaAssociation-Kante bereits eine Verbindung zu einer weiteren Instanz
des anderen Alphas. Hier muss die notwendige Struktur nur um die noch fehlenden
Teile ergänzt werden. Gleichzeitig muss für die bereits an Verbindungen teilneh-
mende Instanz geprüft werden, ob eine Verbindung unter Berücksichtigung der Ma-
ximalanzahl noch möglich ist.
Die LHS der Regel beschreibt die gleiche Situation wie die LHS von Regel 2 mit dem
Zusatz, dass für die Instanz des einen Alphas bereits ein help_InstanceAssociation-
Knoten existiert. Aus diesem Grund muss nur für die noch nicht verbundene Alpha-
Instanz ein help_InstanceAssociation-Knoten erzeugt und dessen Wert für das At-
tribut counter auf 1 gesetzt werden. Der Wert für dieses Attribut im nicht neu erstell-
ten help_InstanceAssociation-Knoten wird um 1 erhöht. Abschließend wird der neu
erzeugte help_InstanceAssociation-Knoten noch mit der Alpha-Instanz und dem an-
deren help_InstanceAssociation-Knoten verbunden.
AC 1 überprüft, ob die Maximalanzahl noch nicht erreicht wurde, indem der Wert
des Attributs startUpperBounds (x) mit dem des Attributs counter (v) verglichen wird.
NAC 2, 3, 4 und 5 legen fest, dass der bestehende help_InstanceAssociation-Knoten
nicht für die Verbindung zu Instanzen eines dritten Alphas benutzt wird. Die Nicht-
Existenz von Verbindungen zwischen der noch isolierten Instanz und Instanzen des
anderen Alphas wird in NAC 6 und 7 für Verbindungen mit der betrachteten Instanz
und in NAC 8 und 9 für Verbindungen mit einer weiteren Instanz überprüft.
Die Aussage, dass die Instanz des Alphas am Ende der AlphaAssociation-Kante
noch isoliert ist, bezieht sich lediglich auf die Nicht-Existenz von Verbindungen zu
Instanzen des anderen betrachteten Alphas. Die Instanz kann über Verbindungen
mit Instanzen weiterer Alphas verfügen.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 24/140
Regel 4: Erzeugen von Verbindungen zwischen Alpha-Instanzen (Rule4)
LHS
RHS
AC 1: v < z ODER z = -1
NAC 2
NAC 3
NAC 4
NAC 5
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 25/140
NAC 6
NAC 7
NAC 8
NAC 9
Textstelle/Beleg:
Basierend auf der Beschreibung der Erstellung und Aktualisierung des „Level 0“-
Modells als Teil der dynamischen Semantik (OMG 2014, S. 106)
Erklärung und Diskussion:
Der dritte Fall bei der Erstellung von Verbindungen stellt eine Spiegelung des zwei-
ten Falls dar. Deswegen wird an dieser Stelle auf eine Erklärung verzichtet.
Regel 5: Erzeugen von Verbindungen zwischen Alpha-Instanzen (Rule29)
LHS
RHS
AC 1: v < x ODER x = -1
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 26/140
AC 2: u < z ODER z = -1
NAC 3
NAC 4
NAC 5
NAC 6
NAC 7
NAC 8
NAC 9
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 27/140
NAC 10
NAC 11
NAC 12
Textstelle/Beleg:
Basierend auf der Beschreibung der Erstellung und Aktualisierung des „Level 0“-
Modells als Teil der dynamischen Semantik (OMG 2014, S. 106)
Erklärung und Diskussion:
Regel 5 beschreibt den letzten Fall bei der Erzeugung von Verbindungen zwischen
Alpha-Instanzen. Hier haben beide Instanzen bereits Verbindungen zu Instanzen
des anderen Alphas. Folglich müssen hier lediglich die zwei help_InstanceAssocia-
tion-Knoten miteinander verbunden werden. Allerdings muss für beide Seiten der
Verbindung die Einhaltung der Maximalanzahl an erlaubten Verbindungen über-
prüft werden.
Die LHS beschreibt dabei den bereits bekannten Teil der Alpha-Instanzen und Al-
phas sowie die zwei help_InstanceAssociation-Knoten, die jeweils mit genau einer
der beiden Alpha-Instanzen verbunden sind. In der RHS muss nun lediglich die
Kante zwischen den help_InstanceAssociation-Knoten ergänzt werden sowie der
Zähler in beiden Knoten jeweils um eins erhöht werden.
In AC 1 und 2 erfolgt die Überprüfung, ob die Maximalanzahl an erlaubten Verbin-
dungen bei einer der beiden Instanzen bereits erreicht worden ist. AC 1 überprüft
dies für die Seite am Anfang der AlphaAssociation-Kante und AC 2 entsprechend
für die Seite am Ende dieser Kante. NAC 3 und 4 dienen der Festlegung, das bereits
verbundene help_InstanceAssociation-Knoten nicht noch einmal verbunden wer-
den dürfen und NAC 5 bis 12 überprüfen, ob die Knoten für Verbindungen zu In-
stanzen eines dritten Alphas benutzt werden und somit nicht einsetzbar sind.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 28/140
Es wäre hier auch möglich, NAC 5 bis 12 durch PACs zu ersetzen oder die erforder-
lichen Bedingungen direkt in der LHS zu definieren. Statt der Aussage, dass die
Knoten nicht für Verbindungen zu anderen Alphas eingesetzt werden dürfen,
würde man in diesem Fall festlegen, dass sie mit Instanzen des jeweils anderen Al-
pha der betrachteten „Alpha Association“ verbunden sein müssen. In diesem Fall
hätte die Regel allerdings mehrfach definiert werden müssen, da die verschiedenen
Richtungen der Kanten jeweils in einer eigenen Regel hätten abgeprüft werden müs-
sen. Für die Integration dieser Bedingung in die LHS ist die Notwendigkeit direkt
ersichtlich, da es nur eine LHS pro Regel geben kann. Mehrere PACs sind automa-
tisch UND-verknüpft, da jede von ihnen eine Situation beschreibt, die zutreffen
muss, damit die Regel angewendet werden darf. (siehe 2.2)
Existieren mehrere NACs müssen diese zwar auch alle erfüllt sein, allerdings ist
durch die enthaltene Negation die Beschreibung sich ausschließender Situationen
möglich. Ist die Struktur der einen NAC im Graphen auffindbar, ist eine Aussage
über weitere NACs nicht mehr nötig, da die Regel als Ganzes bereits nicht mehr
anwendbar ist. Um die Anzahl an Regeln für das Erzeugen von Verbindungen zwi-
schen Alpha-Instanzen nicht noch weiter zu erhöhen, wurde an dieser Stelle eine
hohe Anzahl an NACs bevorzugt. (siehe 2.2)
Regel 6: Erzeugen eines help_BoundsError-Knotens (Rule59)
LHS
RHS
AC 1: a > 0
NAC 2
NAC 3
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 29/140
Erklärung und Diskussion:
Eine weitere Herausforderung, die sich aus den Viele-zu-Viele-Beziehungen zwi-
schen Alpha-Instanzen ergibt, ist die automatische Einhaltung der Minimalanzah-
len. Technisch sind Regeln definierbar, die bei Unterschreitung von Minimalanzah-
len automatisch notwendige Verbindungen und auch Instanzen von Alphas erstel-
len. Im einfachsten Fall könnten die Regeln 1 bis 5 entsprechend angepasst werden.
Die Entscheidung dies nicht zu tun, baut auf folgendem Beispiel auf:
In einem Essence-Modell wird das Kernel-Alpha Stakeholders um ein Sub-Alpha
Stakeholder und das Kernel-Alpha Team um ein Sub-Alpha Member erweitert. Zu-
sätzlich wird definiert, dass ein Member beliebig viele (0 bis n) Stakeholder betreuen
kann und ein Stakeholder genau durch zwei Member betreut wird. Die Zuordnung
eines Members zu einem Stakeholder erfolgt vor allem basierend auf der Wichtig-
keit des Stakeholders und der Erfahrung des Members. Allerdings fließen auch pro-
jektspezifische Kriterien in die Entscheidung ein.
Wie bereits erwähnt ist das Definieren von Graph-Transformationsregeln zum au-
tomatischen Erzeugen der notwendigen Verbindungen, die beim Hinzufügen eines
neuen Stakeholders entstehen, möglich. Die Regeln könnten z. B. eine Gleichvertei-
lung der Verbindungen über alle Mitarbeiter sicherstellen. Im Beispiel wird aber
auch verdeutlicht, dass die Verbindungen auf der Basis bestimmter Kriterien erstellt
werden sollten, die teilweise projektspezifisch festgelegt werden können. Folglich
wären die nach dem oben benannten Schema automatisch erzeugten Verbindungen
in vielen Fällen falsch und müssten somit gelöscht und durch korrekte Verbindun-
gen ersetzt werden. Daher ist eine automatische Erzeugung der Verbindungen im
Beispiel wenig sinnvoll, solange sie nicht für die konkreten Alphas und das Projekt
angepasst wurden. Da eine Situation verallgemeinert auf Verbindungen zwischen
beliebigen Alphas das Finden von sinnvollen Heuristiken noch weiter erschwert,
wurde in dieser Arbeit darauf verzichtet.
In bestimmten Situationen wie z. B. der Erzeugung von Instanzen der Kernel-Alphas
(siehe Regel 108) kann die automatische Erzeugung von Verbindungen zwischen
Instanzen jedoch sinnvoll sein. Diese Regeln können dann für bestimmte Praktiken
oder sogar Projekte definiert werden.
In dieser Arbeit wird zur Durchsetzung der Minimalanzahl vor allem auf den Ein-
satz von Hilfsknoten zurückgegriffen. Diese Regel beschreibt die Definition eines
solchen Hilfsknoten für den Fall, dass eine Minimalanzahl für eine Instanz des am
Ende der AlphaAssociation-Kante befindlichen Alphas unterschritten wird. In der
LHS und AC 1 ist diese Situation beschrieben. Es ist zu beachten, dass diese Regel
aufgrund der höheren Prioritätsstufe vor der Erzeugung einer möglichen Verbin-
dung angewendet werden muss, sofern sie anwendbar ist. Folglich reicht an dieser
Stelle die Prüfung aus, ob der Wert des Attributes endLowerBounds größer als 0 ist.
Da noch keine Verbindungen bestehen können, ist die Minimalanzahl an Verbin-
dungen unterschritten und ein entsprechender Fehlerknoten muss erzeugt werden.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 30/140
In der RHS ist daher ein neuer help_BoundsError-Knoten, der auf die betrachtete
Instanz zeigt und dessen Attribut associationWith den Namen des Alphas am Anfang
der AlphaAssociation-Kante zugewiesen bekommt. Dies dient der Angabe, auf wel-
che Verbindung sich der Fehler bezieht. NAC 2 unterbindet die Erstellung eines Feh-
lerknotens für Instanzen, die bereits einen help_InstanceAssociation-Knoten besit-
zen, und NAC 3 legt fest, dass für jede Verbindung nur ein help_BoundsError-Kno-
ten an eine Instanz angeschlossen werden kann.
Der help_BoundsError-Knoten wird außer in den Regeln für seine Entfernung in
den weiteren Regeln nicht beachtet. Der Knoten dient lediglich als Hinweis, dass bei
dieser Verbindung eine Konsistenzbedingung verletzt ist. Es wäre allerdings denk-
bar, die Anwendung einer Regel zu unterbinden, wenn ein help_BoundsError-Kno-
ten existiert. Dies ist jedoch bei keiner Regel in dieser Arbeit zwingend notwendig
und folglich wird hierauf verzichtet.
Diese Regel hat die Prioritätsstufe 3.
Regel 7: Erzeugen eines help_BoundsError-Knotens (Rule60)
LHS
RHS
AC 1: a > 0
NAC 2
NAC 3
Erklärung und Diskussion:
Diese Regel stellt die Spiegelung von Regel 6 dar, da lediglich die Instanz des Alphas
am Start anstatt des Alphas am Ende der AlphaAssociation-Kante betrachtet wird.
Auf eine Erklärung und Diskussion der Regel wird daher verzichtet.
Die Regel hat die Prioritätsstufe 3.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 31/140
Regel 8: Löschen eines help_BoundsError-Knotens (Rule61)
LHS
RHS
AC 1: a ≤ b
AC 2: c = d
Erklärung und Diskussion:
Die help_BoundsError-Knoten werden entfernt, sobald die notwendige Anzahl an
Verbindungen erstellt wurde. Die LHS beschreibt zwei durch eine AlphaAssocia-
tion-Kante verbundene Alphas mit jeweils einer Instanz. Die zwei Instanzen sind
über help_InstanceAssociation-Knoten miteinander verbunden. In AC 1 wird nun
geprüft, ob der Wert des Attributes counter (b) im help_InstanceAssociation-Knoten,
der mit einer Instanz mit einem Fehler für diese Verbindung verbunden ist, höher
ist als die notwendige Mindestanzahl, in diesem Fall also endLowerBounds (a). In
AC 2 wird sichergestellt, dass der Fehlerknoten sich auf diese AlphaAssociation-
Kante bezieht, indem der enthaltene Name (d) mit dem Namen des Alphas (c) auf
der anderen Seite, in diesem Fall am Anfang der Kante, verglichen wird. In der RHS
ist der help_BoundsError-Knoten nicht mehr enthalten, folglich wurde er aus dem
Graphen entfernt, sofern die Bedingungen in LHS und AC 1 und 2 erfüllt waren.
Die Regel hat die Prioritätsstufe 3.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 32/140
Regel 9: Löschen eines help_BoundsError-Knotens (Rule62)
LHS
RHS
AC 1: a ≤ b
AC 2: c = d
Erklärung und Diskussion:
Diese Regel ist fast identisch mit Regel 8. Den einzigen Unterschied stellt die geän-
derte Richtung der Kante zwischen den help_InstanceAssociation-Knoten dar. Auf
eine Erklärung und Diskussion der Regel wird deswegen verzichtet.
Die Regel hat die Prioritätsstufe 3.
Regel 10: Löschen eines help_BoundsError-Knotens (Rule63)
LHS
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 33/140
RHS
AC 1: a ≤ b
AC 2: c = d
Erklärung und Diskussion:
Wie Regel 8 befasst sich diese Regel mit dem Entfernen eines help_BoundsError-
Knotens. Allerdings wird hier nicht die Instanz des Alphas am Ende, sondern die
Instanz am Anfang der Verbindung betrachtet. Auf eine Erklärung und Diskussion
der Regel wird aufgrund der großen Ähnlichkeit verzichtet.
Die Regel hat die Prioritätsstufe 3.
Regel 11: Löschen eines help_BoundsError-Knotens (Rule64)
LHS
RHS
AC 1: a ≤ b
AC 2: c = d
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 34/140
Erklärung und Diskussion:
Diese Regel ist fast identisch mit Regel 10. Den einzigen Unterschied stellt die geän-
derte Richtung der Kante zwischen den help_InstanceAssociation-Knoten dar. Auf
eine Erklärung und Diskussion der Regel wird deswegen verzichtet.
Die Regel hat die Prioritätsstufe 3.
Regel 12: Erzeugen von Sub-Alpha-Instanzen (Rule5)
LHS
RHS
NAC 1
Textstelle/Beleg:
Basierend auf der Beschreibung der Erstellung und Aktualisierung des „Level 0“-
Modells als Teil der dynamischen Semantik (OMG 2014, S. 106)
Erklärung und Diskussion:
Diese Regel beschreibt die Erstellung einer neuen Instanz für ein Sub-Alpha, falls
noch keine Instanz dieses Sub-Alphas existiert. Wie in Regel 2 argumentiert, kann
die Instanz in diesem Fall ohne Beachtung der Maximalanzahl erstellt werden, da
der Wert 0 für die Maximalanzahl nicht vorgesehen ist. Der Name, der zu erstellen-
den Instanz, muss der Regel mit Hilfe des Parameters inName übergeben werden.
Die Ausgangssituation (LHS) sind zwei Alphas, die mit einer HierarchyCon-Kante
verbunden sind. Das übergeordnete Alpha besitzt zudem mindestens eine Instanz.
In der RHS wird nun eine Instanz des Sub-Alphas erzeugt, deren Attribut instance-
Name den Wert des Input-Parameters inName erhält. Die Instanz des Sub-Alphas
wird abschließend mit einer HierarchyInstanceCon mit der Instanz des übergeord-
neten Alphas verbunden. Das Attribut usedConnections bekommt dabei den Wert 1.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 35/140
NAC 1 legt fest, dass vor der Anwendung dieser Regel noch keine Instanz des Sub-
Alphas der Instanz des übergeordneten Alphas zugeordnet sein darf. Dies stellt
keine Aussage über andere Instanzen des übergeordneten Alphas oder des Sub-Al-
phas dar.
Regel 13: Automatisches Erzeugen von Sub-Alpha-Instanzen (Rule65)
LHS
RHS
AC 1: x > 0
NAC 2
Textstelle/Beleg:
Basierend auf der Beschreibung der Erstellung und Aktualisierung des „Level 0“-
Modells als Teil der dynamischen Semantik (OMG 2014, S. 106)
Erklärung und Diskussion:
Entsprechend der vorherigen Regel wird in dieser Regel die automatische Erstellung
von Instanzen für Sub-Alphas definiert. Zusätzlich zu den Bedingungen aus Regel
12 wird hier eine AC definiert, die festlegt, dass diese Regel nur angewendet werden
kann, wenn die Minimalanzahl an erforderlichen Instanzen unterschritten ist. Der
Name der Instanz wird in diesem Fall automatisch aus dem festen Präfix „Instance
of“ und dem Namen des instanziierten Alphas erzeugt.
Die Definition einer zusätzlichen Regel für diesen Fall liegt in der unterschiedlichen
Priorität der beiden Regeln. Regel 12 hat die Prioritätsstufe 0, stellt also eher manu-
elle Vorgänge dar, während diese Regel mit der Prioritätsstufe 2 automatisch ausge-
führt werden sollte. Eine gemeinsame Regel würde entweder nicht automatisch aus-
geführt oder für jedes Alpha immer eine Instanz des Sub-Alphas erstellen. Eine
Trennung der Regel ist also erforderlich.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 36/140
Bei Sub-Alphas wird nicht wie bei gleichwertigen Alphas auf Fehlerknoten zurück-
gegriffen, um die Minimalanzahl an Instanzen durchzusetzen, da die Instanzen für
Sub-Alphas in den hier definierten Regeln immer nach und in Abhängigkeit von
Instanzen übergeordneter Alphas erstellt werden. Eine Zuordnung der Instanzen ist
also fest gegeben und muss nicht künstlich hergestellt werden. Die in Regel 6 be-
schriebenen Probleme treten hier also nicht auf.
Die Regel hat die Prioritätsstufe 2.
Regel 14: Erzeugen von Sub-Alpha-Instanzen (Rule6)
LHS
RHS
AC 1: z < y ODER y = -1
AC 2: a ≠ z
NAC 3
Textstelle/Beleg:
Basierend auf der Beschreibung der Erstellung und Aktualisierung des „Level 0“-
Modells als Teil der dynamischen Semantik (OMG 2014, S. 106)
Erklärung und Diskussion:
Diese Regel beschreibt den Fall der Erstellung einer weiteren Instanz eines Sub-Al-
phas mit Bezug zu einer übergeordneten Alpha-Instanz. Wie in Regel 12 wird auch
hier der Name der neuen Instanz mithilfe des Parameters inName übergeben. Da
bereits eine beliebige Anzahl von Instanzen des Sub-Alphas für die betrachtete über-
geordnete Alpha-Instanz bestehen kann, muss hier auch die Einhaltung der Maxi-
malanzahl von Instanzen betrachtet werden.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 37/140
In der LHS wird entsprechend die Existenz von einem Alpha und verbundenen Sub-
Alpha beschrieben. Beide wurden bereits mindestens einmal instanziiert und diese
Instanzen sind miteinander verbunden. In AC 1 wird geprüft, ob der Wert von
usedConnections (z) kleiner ist als der Wert des Attributs upperBounds (y) oder ob y =
-1 ist, also unendlich viele Verbindungen erlaubt sind. Vereinfacht gesagt wird ge-
prüft, ob die Erstellung einer weiteren Instanz die Maximalanzahl überschreiten
würde.
AC 2 und NAC 3 dienen der Sicherstellung der Konsistenz des usedConnections-Zäh-
lers, indem die Ausführung nur erlaubt wird, wenn an allen relevanten Kanten das
Attribut usedConnections den gleichen Wert besitzt. In AC 2 wird auf Ungleichheit
geprüft, da sie zusammen mit NAC 3 eine nicht gewünschte Situation beschreibt.
Die geprüfte Bedingung ist, dass es keine relevante Kante geben darf, die einen an-
deren Wert für usedConnections hat als die Kante im LHS-Graphen.
Sind diese Bedingungen alle erfüllt, wird in der RHS eine weitere Instanz erzeugt,
deren Attribut instanceName auf den Wert des Parameters inName gesetzt wird. Der
Wert des Attributs usedConnections an der bereits vorher bestehenden Kante wird
um eins erhöht und danach als Wert für die neue Kante übernommen.
Regel 15: Automatisches Erzeugen von Sub-Alpha-Instanzen (Rule66)
LHS
RHS
AC 1: x > y
AC 2: a ≠ y
NAC 3
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 38/140
Textstelle/Beleg:
Basierend auf der Beschreibung der Erstellung und Aktualisierung des „Level 0“-
Modells als Teil der dynamischen Semantik (OMG 2014, S. 106)
Erklärung und Diskussion:
Entsprechend der doppelten Definierung der Regel 13 stellt diese Regel die automa-
tische Variante von Regel 14 dar. Zusätzlich zu den Bedingungen von Regel 14, ist
diese Regel nur anwendbar, solange der Wert des Attributs usedConnections (y) klei-
ner ist als der Wert des Attributs lowerBound (x) (AC 1).
Für eine genauere Beschreibung dieser Regel siehe Regel 13 und 14.
Die Regel hat die Prioritätsstufe 2.
Regel 16: Abgleich der Zähler an HierarchyInstanceCon-Kanten (Rule7)
LHS
RHS
AC 1: x >y
Erklärung und Diskussion:
Mit Graph Transformationsregeln kann in der LHS und RHS immer nur eine feste
Anzahl an Kanten erfasst werden (siehe 2.2). Aus diesem Grund werden an den Hie-
rarchyInstanceCon-Kanten und auch an anderer Stelle Zähler eingesetzt, um eine
beliebige Anzahl an Kanten erfassen zu können. Die Herausforderung bei der Be-
ziehung eines Alphas und eines Sub-Alphas ist die Tatsache, dass mehrere Instanzen
des Alphas erzeugt werden können. Ein Zähler an der HierarchyCon-Kante auf „Le-
vel 1“ ist also nicht möglich. Als Lösung für diese Arbeit wurde deswegen das At-
tribut usedConnections definiert, das die Anzahl an existierenden Kanten erfasst. Die-
ses Attribut existiert an allen Kanten zwischen einer Alpha-Instanz und Instanzen
eines bestimmten Sub-Alphas und hat für alle diese Kanten den gleichen Wert.
Eine mögliche Alternative hierzu wäre die Definition eines Hilfsknotens als zentra-
len Zähler nach Art des help_InstanceAssociation-Knoten. Die gewählte Lösung ist
unter dem Anspruch, möglichst wenig Hilfsknoten einzusetzen und eine einfache
Definition der Regeln zu ermöglichen, eine akzeptable Wahl.
-
Allgemeine Regeln der dynamischen Semantik
Eine formale Beschreibung der dynamischen Semantik von ESSENCE Seite 39/140
Diese Regel wird im Anschluss an Regel 14 und 15 angewendet, sobald mehr als
zwei Instanzen eines Sub-Alphas für eine übergeordnete Alpha-Instanz erzeugt
wurden. Dadurch wird sichergestellt, dass alle Kanten entsprechend erhöht werden
und nach einfacher oder mehrfacher Ausführung dieser Regel alle Kanten wieder
den gleichen Wert für das Attribut usedConnections haben.
In der LHS wird dafür die Situation beschrieben, dass zwei Instanzen eines Sub-
Alphas einer Alpha-Instanz zugeordnet sind. Auf diese Weise werden nur Kante
verglichen, die miteinander in Beziehung stehen, nicht aber Kanten von Instanzen
verschiedener Sub-Alphas oder verschiedener übergeordneter Instanzen. In AC 1
wird dann geprüft, ob die Werte des Attributs usedConnections der einen Kanten
(x) und der anderen Kante (y) nicht identisch sind. Ist dies der Fall wird in der RHS
der höhere Wert für beide Kanten übernommen. In AC 1 wird nicht auf Ungleichheit
geprüft, da dies die Definition der