Folien (4up) - Benjamin Braatz

Semantische Konsistenz Objekt-Orientierter 

Viewpoint-Spezifikationen 

Gunnar Schröter, Benjamin Braatz, Markus Klein 

Projekt IOSIP 

Kolloquium des DFG-SPP “Software-Spezifikation” 

Stuttgart, 20. November 2003 

Konsistenz von OO Viewpoints 

Überblick 

Rückblick und Motivation (Phasen 1 und 2; G. Schröter) 

– Viewpoint-Spezifikationen 

– semantische Integration 

– Integrationsmodell 

– bisherige Ergebnisse 

integrierte objektorientierte Spezifikationstechnik (Phase 3; B. Braatz) 

Überblick 

– Semantische Modelle – Objekt-Orientierte Transformations-Systeme (OOTS) 

– Perspektiven – Eigenschaften von OOTS 

– Konsistenz-Prüfung – Konstruktion kanonischer Modelle 

Entwicklungs-Relationen (z.B. Verfeinerung, Bisimulation, Reduktion, ...) für 

Viewpoint-Spezifikationen (G. Schröter) 

DFG-SPP-Kolloquium, 20.11.2003 1 


Motivation für Viewpoint-Spezifikationen 





reale technische Systeme sind aus einer 

Vielzahl unterschiedlicher Perspektiven betrachtbar 

(Struktur, Zeitabhängigkeiten, Kommunikation, ...) 

– in der Gesamtheit schwer in einerTechnik beschreibbar 

– einzelne Perspektiven sind (jeweils) durch einzelne (UML-)Techniken adäquat 

beschreibbar ( Viewpoint-Spezifikationen) 

System-Spezifikation besteht aus einer Menge von Viewpoint-Spezifikationen, 

die unterschiedliche Perspektiven auf ein System beschreiben 

Spec 1 

Spec 2 

Spec 3 

V 

2 

(M) 

Systemspezifikation: 

Menge heterogener (partieller) Viewpoint-Spezifikationen, 

interpretiert als eine Spezifikation eines Systems 

V 

1 

(M) 

M 

V 

3 

(M) 

M 


DFG-SPP-Kolloquium, 20.11.2003 5




Transformations-Systeme 

Integration Viewpoint-Spezifikationen 

Motivation für Transformations-Systeme 

Spec 1 

Spec 2 

Spec 3 

Mod(Spec 2) 

? 

M 

gesucht ist ein formaler semantischer Bereich: 

– unterschiedlichste Aspekte von ingenieurwissenschaftlichen Anwendungsgebieten 

adäquat modellierbar 

– technisch handhabbar 

Mod(Spec 1) 

Mod(Spec ) 3 

Transformations Systeme (TS) (entwickelt in Phase 1 + 2; MGR01) 

Mod(SysSpec) 

SysSpec ist konsistent 









CG: 

m 

D DSig 

: 

D1 

ac1 

D2 

ac3 

D4 

ac4 

ein TS enthält: 

– einen Transitionsgraphen , genannt Control Graph, 

– einen Transitionsgraphen , genannt Data Space (induziert über einer Data 

Space Signature ), 

– einen Transitions-Graph-Morphismus , genannt Labeling- 

Morphismus 

allg. Kompositionsoperationen 

ac2 

allg. Entwicklungsrelationen 

D3 





Aspektmodellierung mit Transformations-Systemen 


Weiterentwicklungen in der 3. Projekt-Phase 

Objekt-Orientierte Transformations-Systeme 

Mit TS adäquat modellierbar: 

Semantiken und Kompositionsoperatoren von 

– CCS, CSP 

– Petrinetze 

– Unity 

– Statecharts 

– Classdiagrams 

– MSC’s 

Entwicklungsrelationen 

– Data-Refinement 

– LOTOS-Entwicklungsrelationen (Trace-Equivalence, -Refinement, Extension, 

Reduction, Testequivalence, starke und schwache Bisimulation) 

– Reynold’s Methode zur Programmverfeinerung 

Modellierung von objekt-orientierten Software-Systemen 

Definition von Perspektiven 

Spezifikation von Perspektiven mit UML-Techniken 

Algorithmischer/konstruktiver Konsistenz-Check 

Def. von Entwicklungsrelationen für einen formalen Top-Down-Entwurf 

Syntaktische (UML-)Regeln für diese Entwicklungsrelationen 

Entwicklung eines Komponentenkonzept 







Struktureller Viewpoint 


Perspektive: Struktur der Datenzustände und Aktionen im OOTS 

Objekt-Orientierte Tranformations-Systeme (OOTS) sind eine Spezialisierung der 

Transformations-Systeme zur Modellierung objekt-orientierter Software-Systeme 

Kontroll-Graph-Ebene (wie TS) 

Spezialisierung der Daten-Raum-Ebene 

– Objekt-Konfigurationen als Datenzustände 

– Ereignisse (Methoden-Aufrufe, Methoden-Beendungen, Attribut-Veränderungen) 

als Aktionen 

object sorts: List, ListElem 

attributes: first: List ListElem 

current: List ListElem 

next: ListElem ListElem 

content: ListElem Int 

actions: createList call : List 

createList ret : List 

Spezifikations-Technik: Klassen-Diagramm 

List 

-current: ListElem 

+ createList(): List 

+insert(Int) 

+start(): Int 

+step(): Int 

insert call : List Int 

insert ret : List 

start call : List 

start ret : List Int 

ass first : List ListElem 

ass current : List ListElem 

. . . 

first 

ListElem 

0..1 next 

-content: Int 

0..1 

+ createListElem(Int): ListElem 

+getContent(): Int 

+setNext(ListElem) 

+getNext(): ListElem 

+existsNext(): Bool 




Statischer Viewpoint 




Methoden-Effekt-Viewpoint 

Perspektive: Statischer Anteil des OOTS 

Perspektive: Datenzustands-Effekte von Methoden im OOTS 

data sorts: Int SP Int = 

data opns: zero: Int zero SP = 0 

succ: Int Int succ SP (i) = i+1 

pred: Int Int pred SP (i) = i-1 

add: Int Int Int add SP (i,j) = i+j 

Spezifikations-Technik: Algebraische Spezifikation 

 

Int 

+zero(): Int 

+succ(Int): Int 

+pred(Int): Int 

+add(Int,Int): Int 

succ(pred(i))=i 

pred(succ(i))=i 

add(i,zero)=i 

add(i,succ(j))=succ(add(i,j)) 

add(i,pred(j))=pred(add(i,j)) 

ll:List 

ll:List 

ll:List 

first 

first 

le1:ListElem 

content=23 

le1:ListElem 

content=23 

ll.insert(42) 

ll.insert(42) 

ll.insert(23) 

ll:List 

ll:List 

ll:List 

first 

first 

first 

Spezifikations-Technik: OCL-Constraint an Methode 

le2:ListElem 

content=42 

le1:ListElem 

content=42 

le2:ListElem 

content=23 

context List::insert(i: Int) 

post: first.next = first@pre 

first.content = i 

next 

next 

le1:ListElem 

content=23 

le1:ListElem 

content=23 





Methoden-Struktur-Viewpoint 

Perspektive: Strukturierung von Methoden im OOTS 


Kontrollfluss-Viewpoint 

Perspektive: Aufrufbarkeit von Methoden im OOTS 

getContent call(le) 


getContent ret(le,i3) 

ll:List 

first 

(ll) start call 

le1:ListElem 

content=23 

(le1) 

ass current 

getContent call(le1) getContent ret (le1,23) 

ll:List 

first 

current 

le1:ListElem 

content=23 

Spezifikations-Technik: Methoden-Beschreibung in einer Action Language 

method List::start():Int 

current := first 

return current.getContent() 

start ret (ll,23) 

in 

createListElem call(le,i1) 

getContent call (le) 

createListElem ret(le) 

existsNext ret (le,b1) 

getContent ret (le,i2) 

setNext call (le,le1) 

existsNext call (le) 

setNext ret (le) 

existsNext ret (le,b2) 

Spezifikations-Technik: Statechart-Diagramm für Klasse 

getContent,existsNext 

getContent,setNext,getNext,existsNext 

setNext call (le,le2) 

getNext ret (le,le3) 

(le) 

existsNext call 

setNext ret (le) 

getNext call (le) 

createListElem 

next unset 

setNext 

next set 




Kontrollfluss-Viewpoint 



Konsistenz-Prüfung 


Wenn kein Kontrollfluss spezifiziert ist, ist implizit jede Methode immer aufrufbar. 

Spec 1 

Spec 2 

Spec 3 

in 

insert call (ll,i1) 

insert ret (ll) 

start call (ll) 

Mod(Spec 2) 

createList call(ll) 

createList ret (ll) 

step ret (ll,i3) 

start ret (ll,i2) 

step call (ll) 

Mod(Spec 1) 

Mod(Spec ) 3 

M 

insert,start,step 

createList 

created 

Mod(SysSpec) 

Perspektiven-Modelle für die einzelnen Viewpoint-Spezifikationen 

Konstruktion eines (kanonischen) System-Modells für die System-Spezifikation 

Konsistenz, wenn dieses Modell existiert 

Inkonsistenz, wenn es nicht existiert 




Konsistenz-Prüfung zwischen den Perspektiven 



Beheben der Inkonsistenz 


Behebung durch neue Kontrollfluss-Spezifikation 

in 

cL c (l) 

cL r (l) 

sta c (l) 

sta r (l,i1) 

in 





start call (ll) 

createList call (ll) 

createList ret(ll) 

insert call(ll,i1) 

insert ret(ll) 

start call(ll) 

start ret(ll,i3) 

step ret (ll,i6) 

start ret (ll,i5) 

step call (ll) 

in 

insert 

insert,start,step 

createList 

empty 

insert 

current unset 

start 

current set 

cL r (l) i c (l,42) 

cLE r (e1) 

i r (l) 

cL c (l) 

cLE (e1,42) 

l c 

l e1: 

a cont (e1,42) 

a l e1:42 first (l,e1) 

l 

e1:42 




Konsistenz-Prüfung zwischen den Perspektiven 



Entwicklungs-Relationen 

Konzept von Entwicklungs-Relationen für Systemspezifikationen 

in 

cL c (l) 

cL r (l) 

i c (l,i1) 

i r (l) 

Spec 1 

Spec2 

R 

2 

R 1 

V (M) 

2 

Spec 3 

R 

3 

V 

1 

(M) 

V 

1 

(E) 

M 

V 

3 

(M) 

M 

in 

Spec 1 

‘ Spec‘ 

2 

V 

2 

(E) 

E 

V 

3 

(E) 

Spec‘ 

3 

V (N) 

2 

cL r (l) i c (l,42) 

cLE r (e1) 

i r (l) 

cL c (l) 

cLE (e1,42) 

l c 

l e1: 

a cont (e1,42) 

a l e1:42 first (l,e1) 

l 

e1:42 

V 

1 

(N) 

N 

V 

3 

(N) 




Entwicklungs-Relationen für OOTS 



Konsistenz von Entwicklungsschritten 


Identifizierung/Definition der notwendigen Entwicklungsrelationen ( ODEMA) 

Spec 1 

Spec2 

R 

2 

R 1 

V (M) 

2 

Spec 3 

R 

3 

Zerlegung in Entwicklungsrelationen 

auf den Perspektiven 

syntaktische Repräsentation von 

– korrekte und 

– vollständige 

Regelmengen 

durch 

Spec 1 

‘ 

V 

1 

(M) 

Spec‘ 

2 

M 

E 

V 

3 

(M) 

Spec 3 

‘ 

M 

Entwicklung von Konsistenzkriterien für Entwicklungschritte 

M( Spec‘ 

2) 

M( Spec 1 

‘) 

? 

M( Spec 3 

‘) 




Verfeinerung von Methoden 

Methodenverfeinerung 


Beispiel für Methodenverfeinerung 


eine (abstrakte) Methode wird 

– mittel Kompositionsoperatioren (sequentiell, alternativ, Fixpunkt) 

– über anderen (konkreteren) Methoden 

strukturiert (implementiert) 

move 

body 

(p,7,16) 

move 

call 

(p,7,16) x(p) = 42 

x(p) = 49 

y(p) = 13 

y(p) = 29 

move ret(p) 




Beispiel für Methodenverfeinerung 



Zerlegung der Methodenverfeinerung 


Methodenverfeinerung hat Effekte auf: 

ass x(p,7) 

ass 

move 

call 

(p,7,16) x(p) = 42 x(p) = 49 

y(p,16) 

x(p) = 49 

y(p) = 13 y(p) = 13 y(p) = 29 

move ret(p) 

– Abstrakte Methoden-Perspektive 

Reduktion des Nichtdeterminismus 

Verstärkung der Postcondition 

Domänenerweiterungen 

Abschwächung der Precondition 

– Konkrete Methoden-Perspektive 

Strukturierung des Methodenbody 

Konkretisierung des Methodenablaufs 

sonst keine Effekte ( 

Diagonalrelationen) 

Inkonsistenzen möglich 

algorithmisch entscheidbare Konsistenzkriterien notwendig 




Zusammenfassung 



Ausblick 


Entwicklung des TS-Framework 

Validierung der Nutzbarkeit anhand der Modellierung von verschiedensten formalen 

– semantischen Bereichen, 

– Kompositionsoperatoren, 

– Enwicklungsrelationen 

TS-Semantik insb. für: 

– Classdiagrams 

– Statecharts 

Enwicklung von OOTS 

Entwicklung einer formalen, heterogenen Spezifikationsmethode für objektorientierten 

Softwareentwurf mit 

adäquater Spezifikation der Viewpoints durch UML-Techniken 

erweiterbar/offen für die Integration weiterer Aspekte 

formalen und algorithmisch entscheidbaren Konsistenzkriterien 

kompositionaler Semantik 

formalen Entwicklungsrelationen

Folien (4up) - Benjamin Braatz

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?