Transformation von Operatoren in Prozeduren

Mit SDL-2000 müssen Operatoren durch Angabe eines Algorithmus definiert werden (Ausnah-me bilden die Operatoren der vordefinierten Datentypen). Der Semantik algorithmischer Ope-ratoren in SDL-96 folgend, werden OpeOpe-ratoren in SDL-2000 in Prozeduren umgeformt. Die

Abarbeitung eines Operators und einer Prozedur erfolgt in der dynamischen Semantik dann auf die gleiche Weise.

Die Umformung von Operatoren in Prozeduren wird durch die folgende informale Definition festgelegt

An <operation definition> is transformed into a <procedure definition> or <procedure dia-gram> respectively, having anonymous name, having <procedure formal parameters> de-rived from the <formal operation parameters>, and having a <result> dede-rived from the

<operation result>. The <procedure body> is derived from <operation body> if one was present, or, if the <operation definition> contains a <statement list>, the result of this trans-formation is a <procedure definition> (see 9.4). After the Model of <procedure definition>

has been applied, the virtual start inserted by that Model is replaced by a start without <vir-tuality>.

An <operation diagram> is transformed into a <procedure diagram> in a similar manner.

The Procedure-definition corresponding to the resultant <procedure definition> or <proce-dure diagram> is associated with the Operation-signature represented by the <operation sig-nature>.

If the <operation definition> or <operation diagram> defines a method, then during the trans-formation into a <procedure definition>, or <procedure diagram> an initial parameter with

<parameter kind> in/out is inserted into <formal operation parameters>, with the argument

<sort> being the sort that is defined by the <data type definition> that constitutes the scope unit in which the <operation definition> occurs. The <variable name> in <formal operation parameters> for this inserted parameter is a newly formed anonymous name.

Beispiel 39. Gegeben sei die Operatordefinition

operator fib(n Integer)->Integer {

if(n<2) return 1;

else

return n * fib(n-1);

}

Nach Anwendung dieser Transformationsregel entsteht die Prozedurdefinition (in textueller Syntax)

procedure anon_1(n Integer)->Integer;

{

if(n<2) return 1;

else

return n * fib(n-1);

}

Für die Operation fib wird zusätzlich vermerkt, dass die Prozedur anon_1 die Operationsde-finition enthält.

Wie aus der Transformationsregel ersichtlich ist, gibt es eine Reihe von Alternativen, die bei der Transformation zu berücksichtigen sind, beispielsweise, ob ein Operationsdiagramm (also gra-fische Syntax) oder eine Operationsdefinition (textuelle Syntax) zu transformieren sind und ob es sich um einen Operator oder eine Methode handelt.

Diese Alternativen sind in der Formalisierung der Transformationsregel teilweise irrelevant, da in der abstrakten Syntax 0 bereits die Unterscheidung zwischen textueller und grafischer

Syntax hinfällig ist. Die Unterscheidung zwischen Operatoren und Methoden muss hingegen berücksichtigt werden. Die sich daraus ergebende Transformationsregel lautet

let nn = newName in

od = <operation definition>(use, <operation heading>(kind, *, *, name, params,

<operation result>(var, sort), raises), entities, body) provided od.operatorProcedureName = undefined

=5=>

<procedure heading>(undefined, undefined, nn, empty, undefined, undefined, (if kind = method then

< <formal procedure parameter>(inout, <parameters of sort>(< thisname >, parentAS0ofKind(od, <data type definition>).identifier0)) >

else empty endif) ^∩

< <formal procedure parameter>(p.s-<parameter kind>, p.s-<parameters of sort>) | p in params _>,

<procedure result>(var, sort), raises), entities, makeProcedureBody(body))>

and

od.operatorProcedureName := nn

In dieser Transformation wird von einer Reihe von Hilfsfunktionen Gebrauch gemacht:

• Die Funktion newName liefert anonyme Namen. Die genaue Definition dieser Funktion ist nicht Teil der formalen Semantik (sie ist aus Sicht der Abstract State Machines eine Funk-tion des Typs monitored). Es ist lediglich verlangt, dass sie in jedem Systemzustand einen anderen Wert liefert, der auch verschieden ist von allen Namen, die in der Spezifikation ver-wendet werden.

• Die Funktion operatorProcedureName ist definiert durch

controlled operatorProcedureName: <operation signature> → <identifier>

initially ∀ ο ∈ <operation signature> : o.operatorProcedureName = undefined

Hier handelt es sich um eine ASM-Funktion vom Typ controlled. Sie gibt an, ob für eine

<operation signature> bereits eine Prozedur definiert wurde. Als Seiteneffekt des Transfor-mationsschritts wird diese Funktion (also die Interpretation des Funktionssymbols) geändert.

Da die sonstigen Vorbedingungen der Transformation für alle Knoten des Typs <operation definition> auch nach der Transformation wieder erfüllt sind, würde ohne diese Funktion die Transformationsregel immer wieder ausgeführt.

• Die Funktion getEntities ermittelt die Liste der Definitionen des aktuellen Sichtbarkeitsbe-reichs.

• Die Funktion makeProcedureBody führt die Umsetzung des Operationskörpers in einen Prozedurkörper durch. Sie ist definiert durch

makeProcedureBody(b: <operation body> <statement list>): <procedure body> <statement>* =_def case b of

| <operation body>(onexc, start, actions) => <procedure body>(onexc, start, actions)

| <statement list>(*, *) => <compound statement>(b) otherwise

undefined endcase

Die eigentliche Transformationsregel besteht nun aus vier Teilen:

1. Die Vorbedingung ist für alle Knoten <operation definition> erfüllt, die noch nicht

transfor-miert wurden.

2. Die eigentlich Transformation lässt den Knoten <operation definition> unverändert.

3. Der Liste der Definitionen im umgebenden Sichtbarkeitsbereich wird ein Knoten <proce-dure definition> hinzugefügt, der sich aus dem Knoten <operation definition> im Wesentli-chen durch Übernahme aller Kindknoten ergibt. Dabei wird allerdings für Methodendefinitionen ein weiterer impliziter Parameter eingefügt.

4. Der implizite Namen der Prozedur wird in der Funktion operatorProcedureName abgespei-chert.