Mathematisch-

Naturwissenschaftliche Fakultät

Software Engineering II

Sommersemester 2022
Dr. Michael Striewe

Universität Potsdam
 Mathematisch-
Naturwissenschaftliche Fakultät

Kapitel 3

MDD und Design by Contract

Universität Potsdam
 Implementierung von BPMN Prozessen
(vereinfacht)

BPMN – Operative Prozesse

mit Process-Engine ohne Process-Engine

• Realisierung (ggf. auch Reuse) • Ableitung von Use Cases (…) aus den
der durch die Tasks spezifizierten Prozessen
• Funktionalität • Implementierung der Use Cases
Deployment auf einer Prozess-Engine

Hauptvorteil: Bezug zum ursprünglichen Hauptvorteil: Flexibilität

Modell bleibt erhalten

Hauptnachteil: oft fehlende Erfahrung, Hauptnachteil: Bezug zum

Technologien reifen erst langsam aus ursprünglichen Modell geht verloren
(semantische Lücke nur verschoben)
Universität Potsdam 3
 Vom Geschäftsprozessmodell zum Code

Technische Modelle
Fachliche Modelle
& Infrastruktur

Business IT

Objekte des Objekte des

Gegenstandsbereichs Lösungsbereichs

semantische Lücke

MDD (Model Driven Development): schrittweise Transformation der Modelle

Universität Potsdam 4
 Wesenszüge des MDD

• MDD (Model Driven Development)

– Modelle als primäre Artefakte in der Softwareentwicklung
– Weitgehend automatische Modelltransformationen,
möglichst bis zum Code
– Oft Verwendung von domänenspezifischen
(Modellierungs-)Sprachen (DSL)
• Entspricht Abstraktion „Assembler → höhere
Programmiersprachen”
– leichtere Verständlichkeit
– Konsistenz von Modellen und Code
– Größere Unabhängigkeit von (wechselnden)
Implementierungstechnologien

Universität Potsdam 5
 Exkurs: Modelltransformation

• Analog zur Textersetzung

– „Search and replace“
– Aber auf Graphen (Knoten und Kanten, meist typisiert)
• Vorgehen
– Ersetzungsregel definieren (linke Seite, rechte Seite)
– Match finden
– Ersetzung durchführen

Universität Potsdam
 Exkurs | Beispiel: Ersetzungsregel

1: Liste 1: Liste
last
2: last 2:

next
3: 3:
next next

4: 4:

Linke Seite Rechte Seite

Regel zum Einfügen eines neuen letzten Knotens einer Liste
Universität Potsdam
 Exkurs | Beispiel: Match finden

1: Liste
3: Ein Vorkommen der
linken Seite …
last
4:
2: next 1:Liste
last
first next 2:

3:
next

next 4:

Universität Potsdam
 Exkurs | Beispiel: Ersetzung durchführen

1: Liste last
3:
... wird ersetzt durch
rechte Seite
next
4:
2: next 1:Liste
first next last
2:

next
3:
next

next 4:

Universität Potsdam
 Exkurs: Graphgrammatiken

• Formale Grundlage für Modelltransformationen sind

Graphgrammatiken
– Enthalten mehrere Regeln, ggf. mit Nebenbedingungen
– Analog zu linearen Grammatiken
– Können gewünschte Eigenschaften formal sicherstellen
• Erweiterung: Triple-Graph-Grammatiken (TGG)
– Verbinden zwei unabhängige Graphen über einen
„Klebegraphen“
– Anwendungen:
• Übersetzung von einer formalen Sprache in eine
andere
• Synchrone Manipulation von zwei Artefakten
verschiedener Sprachen

Universität Potsdam
 Exkurs | Beispiel: TGG (Java <-> UPPAAL)

Universität Potsdam
 Exkurs | Beispiel: TGG (Java <-> UPPAAL)

Universität Potsdam
 MDA: ein Ansatz zur Umsetzung des MDD

• MDA (Model Driven Architecture)

– Framework der OMG (Object Management Group)
– Konzepte und Technologien zur Unterstützung der MDD
– plattformunabhängige Modellierung
– Modell-Transformationen

Universität Potsdam 13
 Konzepte der MDA

• Modelle auf drei Abstraktionsstufen

– CIM (Computation Independent Model)
– externe Sicht auf das System auf dem Business-Level („Domain
Model“)
– PIM (Plattform Independent Model)
– vollständige Systemmodellierung (statisch + dynamisch)
– abstrahiert von den Details von Implementierungsplattformen
→ Plattformwechsel beeinflussen diese Modelle nicht
– PSM (Plattform Specific Model)
– Erweiterung der PIM um Details der Implementierungsplattform

• Modelltransformationen
– Automatisierung der Transformation von PIM zu PSM → Konsistenz
– ??? Wie vom CIM zum PIM ???

Universität Potsdam 14
 Vom Geschäftsprozessmodell zum Code

Technische Modelle &

Fachliche Modelle
Infrastruktur

CIM PIM

Business IT

PSM

Objekte des Objekte des

Gegenstandsbereichs Lösungsbereichs

semantische Lücke

MDD in der Terminologie der MDA → automatische Modelltransformation „hinter der Lücke“

Universität Potsdam 15
 Technologien der MDA (Beispiele)

• UML (sehr gut für die Ebene der PIM)

– unvollständige Modelle (keine automatische
Codegenerierung)
• „Programmierung auf graphischer Ebene” zu
aufwendig
• Code müsste nachbearbeitet werden (z.B.
Methodenimplementierung)
(→ Arbeit auf verschiedenen Abstraktionsebenen
vermeiden)
– ausführbare Modelle
• Einschränkung auf geeignete Teile von UML (xUML:
Executable UML)
• Definition einer eindeutigen Ausführungssemantik

Universität Potsdam 16
 Technologien der MDA (Beispiele)

• UML Action Language

– Konstrukte ähnlich wie in höheren Programmiersprachen
• OCL (Object Constraint Language)
– Einschränkungen, Vor- und Nachbedingungen zur
Verhaltensspezifikation
• MOF (Meta Object Facility)
– Rahmen für die Erweiterung von UML um DSLs

Universität Potsdam 17
 MDD versus Agiles Vorgehen

MDD Agiles Vorgehen

• massive Modellierung • Verzicht auf

vor Codierung und
Testentwurf
• viele Dokumente
(Modelle)
• keine/kaum Tools zur
Unterstützung von
testgetriebenem
Vorgehen
ausführliche Modelle
• „schlanke” Dokumente
• schnelle Releases
• testgetriebenes
Vorgehen
•…

→ XMDD (Extreme Model-driven Development)

Universität Potsdam 18
 Fazit von MDD

• Nutzung von Modellen

– Nicht nur zur Kommunikation und Dokumentation
– Auch zur Spezifikation
• Nutzung von Modelltransformation
– Zur Verfeinerung von Modellen
– Zur Überführung von Modellen in Code
• Potenzielle Vorteile:
– Überbrückung der semantischen Lücke
– Reduktion von Programmierfehlern
• Potenzielle Schwierigkeiten:
– Alle Details im Modell vorhanden?
– Code nur korrekt, wenn Modelle korrekt
– Verbindung von Code und Modell erhalten?

Universität Potsdam
 Spezifikation vs Dokumentation

• Dokumentation:
– Beschreibung der Funktionalität eines Programmes in
natürlicher Sprache.
– Beispiel: Die Funktion max(a,b) gibt den größeren der
beiden Werte a,b zurück.

• Spezifikation:
– Beschreibung der Funktionalität eines Programmes in
einer formalen Sprache.
– Beispiel: ∀a,b: (max(a,b) = a ↔ a ≥ b) ∧ (max(a,b) = max(b,a))

Universität Potsdam 20
 Verifikation vs Testen (1)

• Testen (dynamisch, empirisch):

– Überprüfung der Funktionalität eines Programmes durch
Ausführung des Programmes (mit Testeingaben) und
Beobachtung der produzierten Ausgaben auf Fehler.
– Beispiel:
boolean testMax() {
return max(2,3) == 3;
}

– Zeigt „nur“ die Abwesenheit einer vorher definierten

Menge von Fehlern
•…

Universität Potsdam 21
 Verifikation vs Testen (2)

•…
• Verifikation (statisch, deduktiv):
– Überprüfung der Funktionalität eines Programmes durch
Analyse des Programmes und Beweisen einer
gegebenen Spezifikation
– Beispiel:
• Zeige: ∀a,b: (max(a,b) = a ↔ a ≥ b) ∧ (max(a,b) = max(b,a))
• Nimm an: exists a,b: !…
– Funktioniert nicht für beliebig große Programme und
beliebige Eigenschaften

Universität Potsdam 22
 Programmcode ist Spezifikation

• Programmcode …
– ist in einer formalen Sprache geschrieben
– hat eine definierte Semantik
– beschreibt das Verhalten des Programms
=> Alles genauso wie ein Modell
• Compiler kann Spezifikationsfehler erkennen, z. B.:
– Falsche Typen
– Falsche Parameter
• Nicht jede Programmiersprache unterstützt das
– Dynamische Typisierung zur Laufzeit
• Aber man könnte auch noch mehr Informationen im
Programmcode ablegen

Universität Potsdam
 Design by Contract (DbC)

• Erweitertes Konzept „Design by Contract“

– Aus der Programmiersprache Eiffel
– Erfunden von Bertrand Meyer
• Vertrag (Contract) zwischen Klassen und ihren Klienten
(Nutzern)
– Klient: Verpflichtung, bestimmte Bedingungen beim
Aufruf von Methoden der Klasse einzuhalten:
• => Vorbedingungen (Preconditions)
– Klasse: Garantie bestimmter Bedingungen nach dem
Methodenaufruf:
• => Nachbedingungen (Postconditions)

Universität Potsdam 24
 DbC Beispiel (informal)

... Class Divide

Divide div = new Divide();
int result = div.divide (10,5);
...
Vorbedingung: b != 0
public int divide (int a,b) {
return a / b;
Nachbedingung: }
Ergebnis ist korrekt

Universität Potsdam 25
 Verträge

• Vorbedingungen (Preconditions)
– ergänzen Typvereinbarungen der formalen Parameter
• Nachbedingungen (Postconditions)
– ergänzen Vereinbarung des Rückgabetyps
– normal postconditions (erfüllt, wenn keine Exception)
– exceptional postconditions (erfüllt, falls Exception
geworfen wurde)
• Invarianten
– zusätzliche Garantien
– Bedingungen, die unmittelbar vor dem Aufruf und nach
Abarbeitung der Methode erfüllt sind

Universität Potsdam 26
 Vor- und Nachbedingung formal

• Für eine Operation Op sind Vor- und Nachbedingung

erfüllt, wenn gilt:
Wird Op in einem Zustand ausgeführt, der die
Vorbedingung erfüllt, dann terminiert die Ausführung von
Op und jeder Endzustand erfüllt die Nachbedingung.
• Achtung: Auch der Fehlerfall muss die Nachbedingungen
erfüllen, ist also beim Design zu berücksichtigen!
• Die Definition sagt nichts darüber aus, welche Zustände
eingenommen werden, bevor die Operation terminiert.
• Die Definition sagt auch nichts darüber aus, welche Zustände
eingenommen werden, wenn die Operation ohne erfüllte
Vorbedingung ausgeführt wird.

Universität Potsdam
 Invariante formal

• Eine Klasse erfüllt eine Invariante Inv, wenn

– für jede Operation Op und jeden Zustand Z, der sowohl
die Vorbedingung von Op als auch Inv erfüllt, die
Invariante Inv in jedem Endzustand gilt.
– Inv in jedem Zustand gilt, der unmittelbar nach dem
Aufruf eines beliebigen Konstruktors erreicht wird.
• Die Invariante sagt nichts über Terminierung oder die
Gültigkeit von Nachbedingungen aus.
• Die Invariante darf während der Ausführung einer Operation
temporär verletzt werden!

Universität Potsdam
 Liskov‘sches Substitutionsprinzip

• Die formale Definition bestimmt auch, wann eine Klasse (oder

Komponente) gefahrlos durch eine andere ersetzt werden
kann.
• Dies ist möglich, wenn die neue Klasse (bzw. Komponente)
– die gleichen oder stärkere Invarianten
– die gleichen oder schwächere (!) Vorbedingungen
– die gleiche oder stärkere Nachbedingungen
erfüllt als die alte Klasse (bzw. Komponente).
• In objektorientierten Systemen ist dieses Prinzip auch bei der
Verfeinerung von Klassen durch Vererbung zu beachten.

Universität Potsdam
 Schuldzuweisung (Blame Assignment)

Verletzung von Vorbedingungen:

=> Klient muss modifiziert werden

Verletzung von Nachbedingungen oder Invarianten:

=> Methode muss modifiziert werden

Universität Potsdam 30
 Ausführbare Verträge

• Verträge sind ausführbar

– formuliert als ausführbarer Programmcode (z.B. Java-
Code)
– separiert von Programmcode mit der eigentlichen
Programmlogik
– Verletzung der Verträge werden zur Laufzeit erkannt

Universität Potsdam
 Ausführbare Contracts

• Überprüfen der Bedingungen zur Laufzeit belastet die

Performance

• Meist genutzt bei der Entwicklung und beim Testen und

Debugging und entfernt oder deaktiviert vor der Auslieferung

• Deaktivieren bevorzugen

Universität Potsdam 32
 Sprachen zum Formulieren von Verträgen

• Object Constraint Language (OCL)

– gehört zu UML
– komplexe Syntax
• Java Assertions
– gehören zur Java-Syntax (Schlüsselwort assert)
– Java-Anweisung, die von der JVM ausgeführt wird
(Nebeneffekte ?!)
– Ausführung kann durch Schalter aktiviert und deaktiviert
werden
• Java Modeling Language (JML)
– Sprache zur Spezifikation von Interfaces
– benutzt DbC-Elemente als Teil der Sprache

Universität Potsdam 33