Eine formale Beschreibung der dynamischen Semantik von … · 2019. 12. 4. ·...

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 16: LHS von Regel 107 (groß) __________________________________________ 128

Abbildung 17: NAC 1 von Regel 107 (groß) ________________________________________ 128


Abbildung 19: LHS von Regel 108 (groß) __________________________________________ 129


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


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


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


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


Abbildung 2: Alphas des Essence-Kernels


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


Abbildung 3: „Activity Spaces“ des Kernels


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


Grundlegung


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


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


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 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


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


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


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


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.



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.



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“.



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.



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.



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)



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)


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



RHS

NAC 1

NAC 2

NAC 3

NAC 4

NAC 5

NAC 6

Textstelle/Beleg:






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.


LHS



RHS

AC 1: v < x ODER x = -1

NAC 2

NAC 3

NAC 4

NAC 5

NAC 6

NAC 7



NAC 8

NAC 9

Textstelle/Beleg:




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.




LHS

RHS

AC 1: v < z ODER z = -1

NAC 2

NAC 3

NAC 4

NAC 5



NAC 6

NAC 7

NAC 8

NAC 9

Textstelle/Beleg:




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.


LHS

RHS

AC 1: v < x ODER x = -1



AC 2: u < z ODER z = -1

NAC 3

NAC 4

NAC 5

NAC 6

NAC 7

NAC 8

NAC 9



NAC 10

NAC 11

NAC 12

Textstelle/Beleg:




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.



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




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.



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


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.



Regel 8: Löschen eines help_BoundsError-Knotens (Rule61)

LHS

RHS

AC 1: a ≤ b

AC 2: c = d


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.





LHS

RHS

AC 1: a ≤ b

AC 2: c = d


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.



LHS



RHS

AC 1: a ≤ b

AC 2: c = d


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.



LHS

RHS

AC 1: a ≤ b

AC 2: c = d




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.


Regel 12: Erzeugen von Sub-Alpha-Instanzen (Rule5)

LHS

RHS

NAC 1

Textstelle/Beleg:




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.



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:




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.



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.


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:




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.



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



Textstelle/Beleg:




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.


Regel 16: Abgleich der Zähler an HierarchyInstanceCon-Kanten (Rule7)

LHS

RHS

AC 1: x >y


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.



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

Eine formale Beschreibung der dynamischen Semantik von … · 2019. 12. 4. ·...

Documents

Transcript of Eine formale Beschreibung der dynamischen Semantik von … · 2019. 12. 4. ·...