• Keine Ergebnisse gefunden

Typen und Objektorientierung

Seit SDL-92 muss die Struktur des Systems nicht mehr unbedingt aus einer festen Hierarchie von Blöcken und Prozessen bestehen. Statt dessen ist es auch möglich, Typen von Systemen, Blöcken und Prozessen zu bilden und diese flexibel in verschiedenen Systemen zusammenzu-setzen. Typen können unter anderem in folgenden Fällen eingesetzt werden:

1. Durch Definition von Block- und Prozesstypen innerhalb von Paketen (package) kann die gleiche Teilhierarchie in mehreren Systemen verwendet werden.

2. Durch Vererbung (Spezialisierung) von Typen kann ein vorhandener Typ um weitere

Eigen-schaften erweitert werden.

3. Durch Definition virtueller Typen können Typen spät gebunden werden: Der Typ, der für eine Instanzierung verwendet wird, hängt dann von der Spezialisierung des Typen ab, in dem er verwendet wurde.

4. Durch Definition von Kontextparametern kann ein Typ an verschiedene Kontexte angepasst werden. Der so entstehende Typ ist eine abstrakte Typschablone. Von diesem Typ können nicht unmittelbar Instanzen gebildet werden. Statt dessen muss durch die Angabe von aktu-ellen Kontextparametern aus der Typschablone ein Typ gebildet werden.

3.5.1 Typisierung

Die Definition eines Typs (Systemtyp, Blocktyp, Prozesstyp) erfolgt ähnlich zur Definition ei-nes Typs der entsprechenden nicht-typorientierten Struktur. Abbildung 4 definiert einen Block, in dem der Prozess Responder auf Basis des Prozesstyps ResponderTyp definiert wurde.

Durch die Definition eines Prozesstyps können mehrere Prozesse definiert werden, die alle das gleiche Verhalten besitzen8. Zur Definition mehrerer Systeme auf Grundlage der gleichen Typdefinitionen wurden in SDL-92 Pakete (packages) eingeführt. In Paketen können folgende Konstrukte definiert werden:

• Agententypen (System-, Block-, Prozesstypen),

• Signale,

• Signallisten,

• entfernte Prozeduren und Variablen,

• Datentypen,

• Prozeduren und

• Makrodefinitionen (grafische Makros sind in SDL-2000 nicht mehr unterstützt).

Abbildung 4: Verwendung von Typen

8. Streng genommen beschreibt auch schon in SDL-88 eine Prozessdefinition mehrere Prozessinstanzen, da der Prozess eine Prozessinstanzmenge definiert. Jedoch befinden sich all diese Instanzen immer im gleichen Block; Prozesstypen erlauben die Definition gleicher Prozesse in verschiedenen Blöcken oder Systemen.

res_chan ResponderTyp

ICONind

ICONresp ICONconf

ICONreq

Inres_Service

signal ICONreq, ICONind, ICONresp, ICONconf;

Responder:

ResponderTyp Initiator

1(1) Block inres

ini_chan

g

In SDL-2000 dürfen Pakete außerdem

• Zustandstypen (state types),

• Schnittstellendefinitionen (interfaces) und

• Ausnahmedefinitionen (exceptions) enthalten.

In SDL-92 ist die Semantik von Typen durch ein Ersetzungsmodell definiert: Mit jeder Ver-wendung eines Typs wurde eine Kopie aller Eigenschaften des Typs erzeugt, und die Verwen-dung des Typs durch das entsprechende nicht-typorientierte Konstrukt ersetzt. In SDL-2000 ist die Semantik von Typen „direkt“ erklärt. Falls eine Spezifikation nicht-typorientierte Konstruk-te enthält, werden (durch ein Ersetzungsmodell) anonyme Typen eingeführt und diese Kon-strukte durch typbasierte KonKon-strukte ersetzt.

3.5.2 Spezialisierung

Die Behandlung von Vererbung (im SDL-Zusammenhang oft Spezialisierung genannt) erfolgte in SDL-92 für alle relevanten Konzepte im Wesentlichen einheitlich. Vererbung ist in SDL-92 möglich für

• Systemtypen,

• Blocktypen,

• Prozesstypen,

• Servicetypen (das Service-Konzept wurde in SDL-2000 gestrichen),

• Prozeduren,

• entfernte Prozeduren,

• Datentypen und

• Signale.

In SDL-2000 ist Vererbung zusätzlich erlaubt für

• Zustandstypen und

• Schnittstellen.

SDL unterstützt für fast alle dieser Konzepte nur Einfachvererbung. Lediglich für Schnittstellen ist Mehrfachvererbung erlaubt. Bei der Definition eines Typs als Spezialisierung eines anderen erbt der spezialisierte Typ alle Eigenschaften des Basistyps und kann diesen weitere Eigen-schaften hinzufügen.

Die Definition eines Typen als Spezialisierung eines anderen Typen bedeutet in SDL-92 noch nicht, dass diese Typen polymorph verwendet werden können, im Sinne des Liskovschen Substitutionsprinzips [Lis87]. Für die meisten Konzepte ist die Polymorphie auch nicht rele-vant. So war es in SDL-92 nicht vorgesehen (und auch nicht sinnvoll), Referenzen auf Blöcke zu erwerben, so dass die Frage der Polymorphie von Blöcken sich auch gar nicht stellt. Zur Re-ferenzierung von Prozessen war nur ein einziger Datentyp (Pid) vorgesehen, der polymorph Re-ferenzen auf Prozesse beliebiger Typen repräsentieren konnte. Auch die Polymorphie von Prozeduren ist nicht interessant, weil sich auch Prozeduren nicht referenzieren lassen.

Vor allem für Datentypen stellte sich in der Praxis das Fehlen von Polymorphie als Problem dar [Sch02]. Dieser Mangel wurde in SDL-2000 durch das objekt-orientierte Datentypkalkül behoben (siehe Abschnitt 3.4).

Zusätzlich wurde in SDL-2000 Polymorphie von Agentenreferenzen eingeführt, die auf der Basis von Schnittstellen definiert wird. Eine Schnittstelle umfasst dabei eine Menge von Signa-len, die ein Agent konsumieren kann. Bei der Definition des Agenten wird deklariert, welche Schnittstellen er unterstützt. Eine Variable, deren Typ eine Schnittstelle ist, kann polymorph Re-ferenzen auf alle Agenten aufnehmen, die diese Schnittstelle unterstützen.

3.5.3 Virtuelle Typen und virtuelles Verhalten

Um einen Agententyp als Basistyp verwenden zu können, muss sich dieser Typ durch Erweite-rung an die geforderte Anwendung anpassen lassen. Dazu reicht es oft nicht, zu dem Typ ledig-lich weitere Eigenschaften (neue enthaltene Agenten, neue Zustandsvariablen, neue Zustände) hinzuzufügen: Das bereits bestehende Verhalten des Basistyps muss auch geändert werden, um von diesen erweiterten Eigenschaften Gebrauch zu machen.

Zu diesem Zweck erlaubt SDL die Definition virtueller Konstrukte. Wird ein Typ, der virtu-elle Konstrukte enthält, spezialisiert, so können die virtuvirtu-ellen Konstrukte durch neue redefiniert werden.

Dabei gibt es zwei Arten virtueller Konstrukte: Virtuelle Verhaltenskonstrukte und virtuelle Typen.

Virtuelle Typen können im Basistyp zur Definition der Struktur verwendet werden; so kann in einem Blocktyp ein virtueller Prozesstyp definiert und instanziert werden. In der Spezialisie-rung des Basistyps kann der virtuelle Prozesstyp redefiniert werden. Alle InstanzieSpezialisie-rungen des virtuellen Typs verwenden dann die Redefinition. In diesem Zusammenhang gelten auch virtu-elle Prozeduren als Typen – die Rufe der Prozedur sind ihre „Instanzierungen“.

Virtuelle Verhaltenskonstrukte wird durch die Definition virtueller Transitionen und virtuel-ler Methoden definiert; letztere werden in Abschnitt 3.4 vorgestellt.

Virtuelle Transitionen erlauben es, in der Spezialisierung eines Agententyps die Reaktion des Agenten auf den Empfang eines Signals zu ersetzen; die Transition wird dann redefiniert. Als Spezialfall kann sogar die Starttransition als virtuell definiert werden. Der spezialisierte Agent führt dann die Starttransition der Spezialisierung aus.

Eine Redefinition eines virtuellen Typs oder einer virtuellen Transition kann als final dekla-riert werden. Dieser Typ (oder diese Transition) kann dann in weiteren Spezialisierungen des Agententyps nicht mehr redefiniert werden.

3.5.4 Kontextparameter

Um einen Typ möglichst flexibel einzusetzen, ist es wünschenswert, von Details mancher Ei-genschaften des Typs zu abstrahieren und den Typ so allgemein wie möglich zu formulieren.

SDL bietet hierzu das Konzept parametrisierter Typen, die durch Kontextparameter spezialisiert werden. Abbildung 5 definiert einen Prozesstyp, der die Registrierung von Daten realisiert. Um welche Daten es sich dabei handelt, ist für die Logik nicht von Bedeutung. Dies wird durch den nicht weiter eingeschränkten Kontextparameter t definiert. Festgelegt wird lediglich, dass die Registrierung über ein Signal register erfolgt und der Test, ob ein Wert registriert wurde, über das Signal lookup. Auch die Namen der Signale sind hierbei Kontextparameter – instanziert man den Typ, können andere Signalnamen festgelegt werden.

Bei der Definition von Kontextparametern können Bedingungen (constraints) festgelegt werden, die für die Kontextparameter gewisse Eigenschaften fordern, beispielsweise, dass ein Agententenkontextparameter mindestens eine spezifizierte Schnittstelle einhält. Bei Speziali-sierung des parametrisierten Typs müssen die aktuellen Parameter diese Bedingungen einhal-ten.