Durchgängiges Kommunikationsdesign für den strukturalen, objektorientierten Hardware- Entwurf

Transkript

1 Durchgängiges Kommunikationsdesign für den strukturalen, objektorientierten Hardware- Entwurf Dissertation zur Erlangung des Grades eines Doktors der Naturwissenschaften am Fachbereich Informatik der Carl von Ossietzky Universität Oldenburg von Wolfram Putzke Röming

2 Gutachter: Professor Dr. Wolfgang Nebel Professor Dr. Dieter Monjau Tag der Disputation: 30. April , 2001 by the author

3 Danksagung Die vorliegende Arbeit entstand während meiner Tätigkeit als wissenschaftlicher Mitarbeiter am Oldenburger Forschungs- und Entwicklungsinstitut für Informatik - Werkzeuge und -Systeme (OFFIS). Viele der in dieser Arbeit präsentierten Ideen entstanden während meiner Arbeit für das EU-Projekt REQUEST (Nr ) und das interne OFFIS Projekt OO-COM. Mein ausdrücklicher Dank gilt meinem Doktorvater Herrn Prof. Dr. -Ing. W. Nebel für seine großzügige Unterstützung meiner Arbeit und die Zubilligung des notwendigen Freiraums, den eine solche Arbeit benötigt. Herrn Prof. Dr. -Ing. habil. D. Monjau danke ich herzlich für das meiner Arbeit entgegengebrachte Interesse und die freundliche Übernahme des Zweitgutachtens. Weiterhin bedanken möchte ich mich bei meinen Kollegen Dr. G. Schumacher, Dr. M. Radetzki, Dipl. inform. F. Oppenheimer, Dipl. inform. Laila Kabous, Dipl. inform. E. Grimpe, Dipl. inform. Mustafa Cakir und Dipl. inform. R. Biniasch für die vielen wertvollen Diskussionen und Hinweise und ihre Unterstützung beim Korrekturlesen.

4

5 A truely great communication architecture is as elegant as a cathedral you design it, and then you pray a lot. anonymous communication system architect [16]

6

7 Inhalt 1 Einführung 1 2 Grundlagen Objektorientierung Objektbasierte Modellierung Klassifikation Objektorientierte Modellierung Vererbung Polymorphismus Parallele Objekte Objektorientierte Kommunikation Synchronisation von Objekten Adressierung von Objekten Weitere Aspekte Wiederverwendung Wichtige Arbeiten Formale Protokoll Sprachen SDL, SDL Kannel Hardwarebeschreibungssprachen VHDL SUAVE VISTA Synopsys Protocol Compiler (DALI) Andere POOL SystemC

8 ii Inhalt 4 Objective VHDL Klassifikationsansätze Typklassen Vererbung Polymorphismus Kommunikation Strukturklassen Vererbung Polymorphismus Kommunikation Klassifikationsbeziehungen Zusammenfassung Objektorientierte Kommunikationsmodellierung Kommunikationsmechanismen Einfache Prozeßkommunikation Message-Passing Objektorientierter Methodenaufruf Bewertung der Kommunikationsmechanismen Software Ansatz Wiederverwendung von Protokolleinheiten Hardwarespezifische Aspekte Starrer vs. flexibler Kommunikationsmechanismus Kommunikationsmodellierung im Hw-Entwurfsprozeß Kommunikationssynthese Probleme mit dem Objective VHDL Präcompiler-Ansatz Kommunikationsverfeinerung Dimensionen der Kommunikationsverfeinerung Dimension der Datenverfeinerung Dimension der Zeitverfeinerung Dimension der Strukturverfeinerung Dimension der funktionalen Verfeinerung Techniken der objektorientierten Protokollverfeinerung Beispiel Anforderungen an ein Kommunikationsmodell Kommunikationsmechanismus Objektorientierte Kommunikationsmodellierung Reuse Einsatz zur Hardware-Modellierung

9 Inhalt iii 6 Allgemeines Kommunikationsmodell Kapselung von Protokollen durch Klassen Abbildung von Protokollen auf Protokollklassen Kommunikationskanäle Weitere Aspekte Erkennen von statischen, potentiellen Deadlocks Anwendung des allgemeinen Kommunikationsmodells Repräsentation der Methodenaufrufe Umsetzung der Protokollklassen Das Message-Passing Werkzeug Synthese Evaluation Analyse der Kritik Zusammenfassung Erweitertes Kommunikationsmodell Typ-Generizität Interfaces Überlegungen zur Umsetzung mit Objective VHDL Kanäle Überlegungen zur Umsetzung mit Objective VHDL Zusammenfassung Weitere Aspekte Objective VHDL Operations Typ-Generizität Formaler abgeleiteter Typ Formaler diskreter Typ Formaler Integer-Typ Formaler Array-Typ Instanziierung von generischen Typklassen Kanäle Channel Ports Kanalobjekte Kanaltypen Deklaration von Kanaltypen Abgeleitete Kanaltypen

10 iv Inhalt Implementierung der Kanalklassen Interfaces Anwendung von Interfaceklassen Entity Objects Einschränkungen Synthese von Objective VHDL Übersetzung von Kanalklassen Übersetzung von Interfaceklassen Simulation Synthese Übersetzung der Typ-Generizität Übersetzung weiterer Sprachkonstrukte Operations Execute Statement Anforderungen für die Hardwaresynthese Synthese Guidelines Anwendungsbeispiel Das I2C-Protokoll Das I2C-Busprotokoll Datenübertragung vom Master zum Slave Datenübertragung vom Slave zum Master Modellierung des I2C-Protokolls Implementierung des I2C-Protokolls Simulation Synthese Zusammenfassung Zusammenfassung 199 A Message-Passing Werkzeug 203 B Kommunikationsbeispiel 207 C Implementierung I2C-Protokoll 215 D Verzeichniss der Abbildungen 227

11 Inhalt v E Verzeichnis der Beispiele 229 Referenzen 231

12 vi Inhalt

13 Kapitel 1 Einführung 1 Beim Entwurf digitaler Schaltungen kristallisiert sich das Mißverhältnis zwischen den Fortschritten in der Fertigungstechnologie und der Produktivitätsrate im Entwurfsbereich immer mehr als ernsthaftes Problem heraus. Während die Komplexität im Fertigungsbereich im Jahr um durchschnittlich 58 Prozent wächst, geben große Halbleiterhersteller den jährlichen Produktivitätszuwachs mit ca. 20 Prozent an [19]. Die Roadmaps der Halbleiterhersteller [92] zeigen, daß Moores Gesetz, wonach sich die Anzahl der primitiven Logikgatter pro Chip alle drei Jahre vervierfacht, wohl auch in der nahen Zukunft nicht an Gültigkeit verlieren wird. Barke rechnet in [19] vor, daß unter der Annahme der Gültigkeit von Moores Gesetz die Halbleiterhersteller im Jahre 2010 in der Lage sein werden, Chips mit einer Komplexität von 5*10 9 Transistoren zu fertigen. Bleibt der Produktivitätszuwachs im Entwurfsbereich bei ca. 20 Prozent pro Jahr, so rechnet Barke weiter, dann müßten Designteams im Jahre 2010 aus Mitarbeitern bestehen, um einen solchen Chip innerhalb eines Jahres zu entwickeln. Obgleich das skizzierte Szenario lediglich eine Prognose ist, bleibt doch festzustellen, daß im Bereich der Entwurfsmethodik digitaler Schaltungen signifikante Verbesserungen nötig sind, um den beschriebenen Design gap möglichst klein zu halten. Für den Hardware-Entwurf bedeutet dies, daß abstraktere Entwurfsebenen adressiert werden müssen und daß die Automatisierung im Entwurf und die Wiederverwendung bereits entworfener Schaltungen deutlich verbessert werden muß. In der Vergangenheit hat sich gezeigt, daß durch die Einführung von Hardwarebeschreibungsprachen und die damit einhergehende Entwicklung von entsprechenden Werkzeugen die Produktivität im Hardware-Entwurf

14 2 Einführung deutlich gesteigert werden konnte. Dies konnte auch dadurch erreicht werden, daß durch die Verwendung der Hardwarebeschreibungssprachen abstraktere Entwurfsebenen, wie die Register-Transfer und die Verhaltensebene, erschlossen werden konnten. Weiterhin ist zu beobachten, daß die Verwendung von Hardwarebeschreibungssprachen, die heute als Standard betrachtet werden kann, die Methodik des Hardware-Entwurfs dem Entwurf von Software in vielerlei Hinsicht angeglichen hat. Im Bereich der Software-Entwicklung hat das objektorientierte Modellierungsparadigma, welches sich hier inzwischen bereits fest etabliert hat, signifikante Produktivitätssteigerungen bewirkt [57]. Insofern kann erwartet werden, daß die Integration objektorientierter Entwurfsmethoden in den Hardware-Entwurf ähnliche Produktivitätssteigerungen bewirkt. In der Tat wurden in den letzten Jahren diverse Ansätze vorgestellt, um die Objektorientierung für den Hardware-Entwurf nutzbar zu machen. In der Regel basieren diese Ansätze auf der objektorientierten Erweiterung von existierenden Hardwarebeschreibungssprachen. Ein Ansatz hierfür besteht darin, Hardware-Komponenten als Objekte im objektorientierten Sinn zu betrachten. Dieses Vorgehen ist intutitiv, da Komponenten ähnlich wie Objekte Daten und Funktionalität kapseln. Weiterhin erlaubt dieser Ansatz eine strukturale Zerlegung von Entwürfen bereits auf der objektorientierten Entwurfsebene. Bei der objektorientierten Modellierung von wiederverwendbaren Hardware-Komponenten kommt der adäquaten Kommunikations- und Synchronisationsmodellierung eine entscheidende Rolle zu. Es ist jedoch festzustellen, daß die herkömmliche Art der Kommunikationsmodellierung hierfür unzureichend ist, da Kommunikation nicht ausreichend abstrahiert wird. Beispielsweise wird die Kommunikationsschnittstelle einer Hardware- Komponente in der Regel nur durch einen Satz von (Port-) Signalen und durch Datenblätter beschrieben. Diese Arbeit leistet einen wichtigen Beitrag, um dieses Kommunikationsproblem im objektorientierten Hardware-Entwurf zu lösen, indem ein geeignetes Kommunikationsmodell entwickelt und evaluiert wird. Eine der wichtigsten Anforderungen an die Kommunikationsmodellierung stellt dabei die Durchgängigkeit bezüglich der unterschiedlichen Entwurfsebenen dar. Auf der objektorientierten Modellierungsebene muß das Kommunikationsmodell eine angemessene Abstraktion von Kommunikation erlauben. Gleichzeitig müssen die speziellen Anforderungen des Hardware-Entwurfs Berücksichtigung finden. Eine besondere Anforderung stellt die Anbindung

15 der Kommunikationsmodellierung an die Hardware-Synthese dar, um eine synthesegerechte Reimplementierung von Entwürfen zu vermeiden, wenn diese schließlich in Hardware umgesetzt werden sollen. Zum Verständnis der Arbeit wird vorausgesetzt, daß die Grundprinzipien der objektorientierten Modellierung und des sprachbasierten Hardware-Entwurfs bekannt sind. Die Arbeit gliedert sich wie folgt: Kapitel 2 stellt knapp einige wichtige Aspekte der objektorientierten Modellierung dar. Dies geschieht, um dem Leser die Möglichkeit zu geben die Konzepte der Objektorientierung zu rekapitulieren und um die Basis für eine einheitliche Begrifflichkeit zu schaffen. Kapitel 3 stellt anhand unterschiedlicher Entwurfssprachen verschiedene Kommunikationsansätze vor. Dabei werden neben expliziten Hardwarebeschreibungssprachen auch formale Ansätze und Ansätze zur Beschreibung von Hardware/Software-Systemen betrachtet. In Kapitel 4 wird Objective VHDL, eine objektorientierte Erweiterung von VHDL, vorgestellt, da diese in den nachfolgenden Kapiteln zur Illustration und Anwendung der entwickelten Kommunikationskonzepte verwendet wird. Kapitel 5 diskutiert detailliert die Anforderungen und Techniken der objektorientierten Kommunikationsmodellierung und Verfeinerung von Kommunikationsprotokollen im Hardware-Entwurf. Hierbei auftretende Problemstellungen werden motiviert und erste Lösungsansätze vorgestellt. Am Ende dieses Kapitels werden die Anforderungen an ein geeignetes Kommunikationsmodell zusammengefaßt. Basierend auf den identifizierten Anforderungen wird in Kapitel 6 ein allgemeines Kommunikationsmodell vorgestellt. Die Anwendung und Evaluation des Kommunikationsmodells mit Objective VHDL wird in Kapitel 7 vorgestellt. Die Evaluation wird zeigen, daß das Modell tragfähig ist. Da jedoch der Aufwand zur Kommunikationsmodellierung recht groß ist, wird das Modell in Kapitel 8 erweitert, um dessen praktische Anwendbarkeit zu verbessern. In Kapitel 8 werden Spracherweiterungen zu Objective VHDL definiert. Die erweiterte Sprache wird Objective VHDL+ genannt und ermöglicht die einfache Anwendung des erweiteren Kommunikationsmodells. Die Anbindung des erweiterten Kommunikationsmodells an die Hardwaresynthese erfolgt in Kapitel 10, indem Synthesekonzepte für die Objective VHDL+ Erweiterungen vorgestellt werden. Für Objective VHDL existiert bereits eine Anbindung an die Hardware-Synthese [82]. 3

16 4 Einführung In Kapitel 11 schließlich wird die Anwendung des erweiterten Kommunikationsmodells anhand eines Beispiels vorgestellt. Als Beispiel wurde die Implementierung des I2C-Protokolls gewählt. Anhand der Darstellung von Modellierung, Simulation und Synthese des Protokolls wird die Durchgängigkeit der vorgeschlagenen Methode zur Kommunikationsmodellierung gezeigt.

17 Kapitel 2 Grundlagen Objektorientierung Grundsätzlich geht diese Arbeit davon aus, daß die wesentlichen Konzepte des objektorientierten Modellierungsparadigmas bekannt sind. Empfehlenswerte Einführungen sind [34], [60] und [108]. Um das Verständnis der nachfolgenden Kapitel zu erleichtern und um eine für diese Arbeit einheitliche Begrifflichkeit bezüglich objektorientierter Konzepte zu schaffen, werden im folgenden die wichtigsten objektorientierten Konzepte und Begriffe knapp eingeführt Objektbasierte Modellierung Die Konzepte der objektbasierten Modellierung wurden entwickelt, um von der prozeduralen Modellierung, die durch Programmiersprachen wie Pascal, Modula-2, C, Ada etc. repräsentiert wird, zu abstrahieren. Die grundlegende Idee, um dieses zu erreichen, war es, zusammengehörige Daten und Funktionalität zu einer Entwurfseinheit, den Objekten, zusammenzufassen. Ein System besteht dann aus einer Menge von Objekten, die in einer bestimmten (Kommunikations-) Beziehung zueinander stehen. Etwas abstrakter formuliert gibt es drei Merkmale, die ein Objekt charakterisieren: Struktur: Die Struktur eines Objekts wird durch die Daten bestimmt, die das Objekt kapselt. Da die Daten oder genauer die Wertebelegung der entsprechenden Datencontainer den Zustand eines Objekts bestimmen, werden diese als Zustandsvariablen (state variable) bezeichnet. In der objektorientierten Terminologie wird hierfür auch der Begriff Attribut verwendet.

18 6 Grundlagen Die Kapselung der Daten eines Objekts bewirkt, daß diese außerhalb des Objekts nicht sichtbar oder gar zugreifbar sind. Innerhalb des Objekts bestehen aber keine Restriktionen für den Zugriff auf die Objektdaten. Hinweis: Viele objektorientierte Sprachen relativieren das strenge Kapselungskonzept für Datenattribute, indem sie verschiedene Stufen der Datenkapselung unterscheiden. Üblicherweise werden hier drei Stufen unterschieden: Keine Kapselung: Die Datenattribute sind uneingeschränkt von außen zugreifbar. In C++ beispielsweise werden solche Attribute als public bezeichnet. Eingeschränkte Kapselung: Die Datenattribute sind nur von Objekten zugreifbar, die in einer bestimmten Beziehung zum kapselnden Objekt stehen. Als Beispiel können hier die protected Attribute von C++ genannt werden (Vererbungsbeziehung). Vollständige Kapselung: Die Datenattribute sind von außen nicht zugreifbar und somit vollständig gekapselt. Solche Attribute werden in C++ als private bezeichnet. Verhalten: Die möglichen Transformationen, die ein Objekt auf seinen Datenattributen durchführen kann, werden prozedural gekapselt und bestimmen das Verhalten des Objekts. In der objektorientierten Terminologie werden solche Prozeduren als Methoden oder Operationen des Objekts bezeichnet. Die Methoden eines Objekts haben uneingeschränkten Zugriff auf die Datenattribute des Objekts. Daher bewirkt die Ausführung von Methoden in der Regel eine Änderung des Objektzustands. Im Sinne der strengen Datenkapselung kann der Zustand eines Objekts nur verändert werden, indem eine Methode des Objekts aufgerufen wird. Daher sind die Methoden ein wesentlicher Bestandteil des Objektinterfaces. Häufig werden die Methoden deshalb auch als Dienste bezeichnet, die ein Objekt für andere Objekte zur Verfügung stellt. Hinweis: Viele objektorientierte Programmiersprachen bieten die Möglichkeit, die Kapselung der von ihnen zur Verfügung gestellten Dienste zu differenzieren. Die möglichen Kapselungsstufen sind äquivalent zu den Kapselungsstufen für Datenattribute. So ist es beispielswiese möglich Dienste zu definieren, die nur von dem Objekt selbst (private) oder nur von Objekten, die in einer bestimmten Beziehung stehen (protected), genutzt werden können. Werden Objekte im Kontext paralleler Sprachen als nebenläufige Einheiten betrachtet, so gibt es häufig die Möglichkeit ein aktives Verhalten für diese in Form von Prozessen zu definieren. Daher werden solche Objekte auch

19 Objektorientierung 7 als aktive Objekte bezeichnet. Mit der Instanziierung eines aktiven Objekts werden gleichzeitig auch die das aktive Verhalten beschreibenden Prozesse gestartet. Beispiele für Sprachen, die aktive Objekte unterstützen sind POOL2 und Objective VHDL. Schnittstelle nach außen: Die Schnittstelle eines Objekts legt fest, welche Eigenschaften des Objekts für andere Objekte transparent sind bzw. welche Dienste von anderen Objekten genutzt werden können. Dies wird durch die Kapselungsstufe der Datenattribute und Methoden definiert. Daher wird die Schnittstelle eines Objekts in der Literatur häufig auch als encapsulation boundary bezeichnet [108]. Sollen die Objekte eines Objektsystems kommunizieren, so ist es notwendig, daß die Objekte eindeutig identifiziert werden können. In Programmiersprachen hat jedes Objekt üblicherweise einen eindeutigen Identifikator (Namen), der für die Adressierung von Kommunikationswünschen verwendet werden kann. Insofern trägt auch der Identifikator eines Objekts zu dessen Schnittstelle bei. Die Modellierung eines Objektsystems erfordert neben der Modellierung der einzelnen Objekte auch die Festlegung der Beziehungen der Objekte untereinander. Grundsätzlich sind die (Kommunikations-) Beziehungen der Objekte untereinander durch eine Client-Server Beziehung charakterisiert. Das Server-Objekt bietet Dienste an, die vom Client-Objekt genutzt werden. Es ist zu beachten, daß die Client-Server Relation nicht statisch sein muß, da Objekte sowohl Client als auch Server sein können. Wird ein Objekt vollständig durch ein anderes Objekt gekapselt, so ist es ein exklusives Server- Objekt des umgebenden Objekts. Diese Beziehung wird has-a -Relation genannt. Eine andere Beziehung ist die use -Relation, bei der ein Server durch mehrere Clients genutzt werden kann Klassifikation Ein Abstraktionsschritt, um vom konkreten Objekten zu abstrahieren und um deren Wiederverwendbarkeit zu verbessern, ist die Definition von Klassen. Eine Klasse kann quasi als Konstruktionsplan für Objekte betrachtet werden, da sie festlegt, welche Eigenschaften (Attribute, Methoden) ein Objekt haben soll. Konkrete Objekte werden durch Instanziierung von Klassen gebildet. Dabei haben alle Instanzen einer Klasse die gleichen Eigenschaften und unterscheiden sich nur durch deren Instanziierungsnamen (Identifikatoren). Üblicherweise werden die oben beschriebenen Kapselungsstufen für Attribute und Methoden schon in der Klassenbeschreibung definiert.

20 8 Grundlagen Objektorientierte Modellierung Die objektorientierte Modellierung greift die Konzepte der objektbasierten Modellierung auf und erweitert diese um den Polymorphismus und die Vererbung. Während der Polymorphismus die (Kommunikations-) Beziehungen zwischen Objekten abstrahiert, trägt die Vererbung zu einer besseren und automatisierten Wiederverwendung von Klassenbeschreibungen bei Vererbung Die Vererbung ist ein Mechanismus, der einer abgeleiteten Klasse die Wiederverwendung von Klassenbeschreibungen oder Teilen davon ermöglicht. Die abgeleitete Klasse wird häufig als Kind- oder Sohn-Klasse bezeichnet. Die Klasse, von der abgeleitet wird, wird entsprechend Eltern- oder Vater- Klasse genannt. Es hängt nun von einem speziellen Vererbungsmechanismus ab, welche Eigenschaften der Vater-Klasse an die Sohn-Klasse vererbt werden. Üblicherweise werden in den objektorientierten Programmiersprachen alle Datenattribute und Methoden vererbt. Das heißt, eine Sohn-Klasse verfügt automatisch über die Datenattribute und die Funktionalität der Vaterklasse. Daher beschreibt die Vererbung eine is a Relation zwischen Vater- und Sohn Klasse. Die Klassen, die in einer Vererbungsbeziehung zueinander stehen, beschreiben eine Vererbungshierarchie. Grundsätzlich ist bei der Vererbung zwischen einfacher und mehrfacher Vererbung zu unterscheiden. Bei der einfachen Vererbung darf eine Kind- Klasse nur eine Vater-Klasse haben. Bei der Mehrfachvererbung kann eine Kind-Klasse von mehreren Elternklassen erben. Innerhalb einer Vererbungshierachie kann es vorkommen, daß Klassen nur gebildet/abgeleitet werden, um Eigenschaften bzw. ein Methodeninterface zu definieren, das alle abgeleiteten Klassen haben sollen. Eine Instanziierung ist nicht vorgesehen. Solche Klassen werden abstrakte Klassen genannt. Da abstrakte Klassen nicht instanziiert werden, kann in der Regel auf eine Implementierung der Methoden verzichtet werden. Allerdings muß dann jede abgeleitete Klasse, die nicht mehr abstrakt ist, eine Implementierung für die in der Vater-Klasse nicht implementierten Methoden liefern. Neben der Wiederverwendung ermöglicht die Vererbung auch die inkrementelle Verfeinerung der Eigenschaften der Vaterklasse. Dies ist möglich indem eine abgeleitete Klasse die ererbten Attribute/Methoden redefinieren oder neue Attribute/Methoden hinzufügen kann.

21 Objektorientierung 9 Die möglichen Modifikationen einer Klasse im Zuge der inkrementellen Verfeinerung definieren den Grad an Kompatibilität, den eine abgeleitete Klasse in Bezug auf ihre Elternklasse aufweist. Die Kompatibilität bezieht sich hier auf die Substituierbarkeit von Eltern- und Kind- Objekten. Die möglichen Kompatibilitätsklassen und die daraus folgenden Anforderungen an die inkrementelle Verfeinerung werden in der Literatur ausführlich diskutiert [89][107] und sollen daher hier nicht vertieft werden. Hinweis: Die oben erwähnte Redefinition von Klassenattributen in abgeleiteten Klassen sollte vermieden werden, selbst wenn sie erlaubt ist. Zum einen erschwert es das Verständnis der Klassenbeschreibung, wenn sich die Semantik eines Attributes durch die Ableitung ändert. Zum anderen kann die korrekte Funktionalität der ererbten Methoden nicht garantiert werden, da diese für die Attribute der Vater-Klasse definiert wurden. In [107] wird das Verfeinerungskonzept der inheritance with cancellation vorgestellt, das ausdrücklich die Redefinition von Datenattributen und sogar das Streichen von Attributen/Methoden im Zuge der inkrementellen Verfeinerung erlaubt. Jedoch schränkt dieses Verfeinerungskonzept den Grad an Kompatibilität zwischen abgeleiteten Objekten soweit ein, daß, soweit bekannt, keine objektorientierte Sprache existiert, die dieses Verfeinerungskonzept unterstützt Polymorphismus Die Verwendung abstrakter Klassen und die Redefinition von Methoden bei der Vererbung erlaubt es, daß in den Klassen einer Vererbungshierarchie Methoden existieren, die zwar das gleiche Methodenprofil (Namen, Parameterliste) haben aber unterschiedlich implementiert sind. Der Polymorphismus erlaubt nun die einheitliche Nutzung von (Server-) Objekten, die diese Eigenschaft aufweisen. Das heißt, ein Client-Objekt muß bei einem Methodenrequest an solche Server-Objekte nicht unterscheiden, welches nun dertatsächliche der Server ist. Alle Server implementieren ja die gewünschte Methode jedoch mit unterschiedlichem Verhalten. Insofern abstrahiert der Polymorphismus von unterschiedlichen Implementierungen eines Dienstes verschiedener Server-Objekte. 1. Die sichere Anwendung des Polymorphismus (ohne Laufzeitfehler) basiert darauf, daß davon ausgegangen werden kann, daß in einer abgeleiteten, nicht abstrakten Klasse für jede ererbte Methode eine Implementierung vorhanden ist. Bei Anwendung der inheritance with cancellation kann dieses nicht mehr garantiert werden!

22 10 Grundlagen Ein Problem, das im Zusammenhang mit dem Polymorphismus auftritt ist, daß i. a. nicht garantiert werden kann, daß ein Server-Objekt auch wirklich den angeforderten Dienst implementiert. Dies gilt insbesondere dann, wenn das tatsächliche Server-Objekt eines Methodenrequests nicht durch eine statische Analyse ermittelt werden kann. In diesem Fall würde der hieraus resultierende Fehler auch erst zur Laufzeit auftreten. Sind solche Fehler nicht akzeptabel, so muß die Nutzung des Polymorphismus soweit eingeschränkt werden, daß in einer statischen Analyse die jeweiligen Server-Objekte der Methodenaufrufe feststellbar sind. Beispielsweise kann festgelegt werden, daß alle potentiellen Server-Objekte in einer Vererbungshierarchie stehen müssen und daß polymorph nur die Methoden aufgerufen werden dürfen, die in der Wurzel der Vererbungshierachie oder des entsprechenden Zweiges vorhanden sind Parallele Objekte Unter parallelen Objekten sollen Objekte verstanden werden, die von sich aus aktiv sind. Im Gegensatz zu passiven Objekten benötigen aktive Objekte nicht den Ausführungsthread eines Client-Objekts, um aktiv zu werden. Fordert beispielsweise ein Client-Objekt die Ausführung einer Methode eines aktiven Server-Objekts an, so wird die Methode mit dem Thread des Server- Objekts ausgeführt. Arbeiten Objekte parallel, so sind für die Definition eines geeigneten Kommunikationsmechanismus andere Anforderungen als bei passiven Objekten zu berücksichtigen. Beispielsweise muß berücksichtigt werden, daß gleichzeitig mehrere Methodenrequests an ein Server-Objekt geschickt werden oder daß ein Client-Objekt nach dem Senden eines Methodenrequests nicht mehr notwenigerweise blockieren muß, bis das Ergebnis der Methodenausführung vorliegt. Diese und andere Aspekte werden im nächsten Abschnitt diskutiert. Bei aktiven Objekten ist grundsätzlich der Grad der möglichen Parallelität zu differenzieren. Besitzen aktive Objekte nur einen Ausführungsthread, so ist der Grad der Parallelität innerhalb eines Objektsystems charakterisiert durch die Anzahl der Objekte, die gleichzeitig existieren. Die Parallelität eines Objektsystems ist jedoch feiner granulierbar, wenn Objekte mehrere Ausführungsthreads besitzen können. Allerdings sind in diesem Fall Mechanismen nötig, um die Konsistenz der Klassenattribute eines solchen Objekts gewährleisten zu können, da aus den verschiedenen Ausführungsthreads heraus gleichzeitige Zugriffe auf die Klassenattribute möglich sind. Aber selbst

23 Objektorientierte Kommunikation 11 wenn die Konsistenz der Klassenattribute zum Beispiel durch einen Monitor-Mechanismus garantiert werden kann, so besteht weiterhin die Gefahr des nichtdeterministischen Objektverhaltens, wenn keine Aussage darüber gemacht werden kann, in welcher Reihenfolge aus den Ausführungsthreads auf die Klassenattribute zugegriffen wird. Eine mögliche Lösung dieses Problems könnte es sein, daß alle Methoden eines Objekts danach klassifiziert werden, auf welche Klassenattribute sie zugreifen. Das heißt, eine solche Klasse von Methoden nutzt eine Menge von Klassenattributen exklusiv. Nun ist es möglich Methodenrequests, die auf unterschiedlichen Attributmengen arbeiten, gleichzeitig zu akzeptieren und auszuführen. Dieser Ansatz setzt allerdings voraus, daß Zugriffe auf Klassenattribute nur aus Methoden heraus erfolgen. Da im allgemeinen jedoch nicht davon ausgegangen werden kann, daß alle Methoden eines Objekts auf exklusiven Mengen von Attributen arbeiten, wird dieser Ansatz auch eine Einschränkung der möglichen Parallelität mit sich bringen. 2.2 Objektorientierte Kommunikation Der objektorientierte Entwurf basiert auf der Idee, daß ein System durch spezialisierte, kommunizierende Objekte modelliert wird. Insofern ist die Kommunikation zwischen Objekten eine Grundvoraussetzung für die objektorientierte Modellierung. Booch [26] bezeichnet die Eigenschaft von Objekten, sich gegenseitig Nachrichten schicken zu können, auch als ein Schlüsselelement objektorientierter Sprachen. Dabei hat der Nachrichtenaustausch in objektorientierten Sprachen immer die Bedeutung, daß eine Methode, ein Dienst eines Server-Objekts ausgeführt werden soll. Da die Dienste als Methoden implementiert sind, wird der Nachrichtenaustausch auch als Methodenaufruf oder Methodenrequest bezeichnet. Eine detaillierte Betrachtung von nachrichtenorientierter Kommunikation findet sich in [45]. Im folgenden werden einige Aspekte der Kommunikation zwischen parallelen Objekten motiviert Synchronisation von Objekten Wie bereits oben erwähnt, ist die Synchronisation von parallelen Objekten notwendig, um Abhängigkeiten der Objekte untereinander zu modellieren. Grundsätzlich kann die Synchronisation der Objekte entweder über den Zugriff auf gemeinsamen Speicher oder durch den Austausch von Nachrich-

24 12 Grundlagen ten geschehen. Jedoch erscheint die Synchronisation über Nachrichten im objektorientieren Kontext als natürlicher, da der Austausch von Nachrichten ohnehin ein zentrales Konzept der objektorientierten Modellierung ist. Im wesentlichen sollen hier drei Synchronisationskonzepte unterschieden werden: Synchrone Kommunikation: Die Synchronisationsphase dauert den gesamten Zeitraum der Kommunikation an. Für ein Client-Objekt heißt das, daß es mit dem Absenden eines Methodenrequests blockiert wird, bis der Request vom Server-Objekt akzeptiert und ausgeführt wurde und gegebenenfalls die Ergebnisse der Methodenausführung an den Client zurückgeschickt wurden. Häufig wird eine solche Synchronisationsphase auch Rendezvous genannt. Asynchrone Kommunikation: Bei der asynchronen Kommunikation kann ein Client-Objekt nach dem Absenden eines Methodenrequests sofort mit seinen Berechnungen fortfahren. Das heißt, es wird nicht blockiert. In der Regel werden bei asynchronen Kommunikationsmodellen Nachrichtenpuffer verwendet, um zu gewährleisten, daß keine Nachrichten verloren gehen. Server-Objekte lesen die Nachrichten dann aus den Nachrichtenpuffern aus. In Abhängigkeit von der erwarteten Kommunikationsfrequenz muß die Kapazität der Nachrichtenpuffer ausreichend dimensioniert werden. Die asynchrone Kommunikation ist unidirektional vom Client zum Server. Insofern ist die asynchrone Kommunikation nur bedingt für die Modellierung von Methodenrequests anwendbar, da hier typischerweise Ergebnisse an den Client zurückübertragen werden müssen 2. Hierfür müßte der Server dann die Ergebnisse explizit durch eine neue Nachricht an den Client zurückschicken. Synchronisation bei Notwendigkeit (synchronization by necessity): Das Konzept der Synchronisation bei Notwendigkeit [28] vermeidet die grundsätzliche Blockierung der Client-Objekte bei Methodenrequests und ermöglicht gleichzeitig die Rückübertragung von Ergebnissen einer Methodenausführung. Das Abschicken eines Methodenrequests erfolgt zunächst asynchron. Danach kann das Client-Objekt solange mit eigenen Berechnungen fortfahren, bis die Ergebnisse des Methodenrequests benötigt werden. Nun wird das Client-Objekt solange blockiert, bis eine Nachricht vom Server-Objekt 2. Eine Einschränkung, um die Anwendung der asynchronen Kommunikation zu ermöglichen, wäre es, diese nur für Methodenrequests zuzulassen, die keine Ergebnisse produzieren, die zurückübertragen werden müssen.

25 Objektorientierte Kommunikation 13 mit den benötigten Ergebnissen eintrifft. Weiterhin ist zu beachten, daß die Synchronisation von Objekten vom Zustand des Server-Objekts oder der Art der übertragenen Nachricht abhängen kann. Das heißt, das Server-Objekt akzeptiert in Abhängigkeit von seinem Zustand und/oder der Art der Nachricht bestimmte Kommunikationsrequests oder lehnt diese ab. Diese Art der Synchronisation wird conditional synchronization genannt. Es ist jedoch darauf hinzuweisen, daß diese Synchronisationsart im Zusammenspiel mit der Vererbung zu Fehlverhalten bei abgeleiteten Objekten führen kann. Dieses Problem wird als Vererbungsanomalie bezeichnet und rührt daher, daß Synchronisationscode an abgeleitete Objekte vererbt wird, die andere Synchronisationsbedingungen benötigen. Die Modifikation der ererbten Synchronisationsbedingungen erfordert in der Regel eine Analyse und gegebenenfalls eine Reimplementierung des Synchronisationscodes [15][58][87] Adressierung von Objekten Eine weitere Voraussetzung für die Kommunikation zwischen Objekten ist es, daß ein Mechanismus existiert, der die Adressierung von Objekten erlaubt. Hierbei ist zunächst zu unterscheiden ob ein einzelnes Objekt, mehrere Objekte oder gar alle Objekte eines Objektsystems (broadcasting) adressiert werden sollen. In objektorientierten Programmiersprachen wird häufig der Name eines Objekts benutzt um festzulegen, an welches Objekt eine Nachricht geschickt werden soll. Dies erlaubt es einem Objekt alle anderen Objekte zu adressieren, die sich im Sichtbarkeitsbereich des Objekts befinden. Insbesondere gilt dies auch für dynamisch erzeugte Objekte. Können die Namen von Objekten zudem noch in Variablen gespeichert werden, so ist auch die Adressierung polymorpher Objekte möglich. Wird auf die dynamische Erzeugung von Objekten verzichtet, so ist auch eine indirekte Adressierung über eine statische Verbindungstopologie möglich. Die Verbindungstopologie legt die möglichen Kommunikationsverbindungen zwischen Objekten fest. Das heißt, ein Objekt kann nur mit anderen Objekten kommunizieren, zu denen es eine Verbindung gibt. Sind die Interobjektverbindungen 1:1 Verbindungen, so kann aus Sicht des Clients der gewünschte Server indirekt über die Verbindung adressiert werden. Auf der anderen Seite kann der Server über die Verbindung erkennen, von welchem Client eine Nachricht kommt. Diese Art der indirekten Adressierung hat zwei Vorteile:

26 14 Grundlagen Kosten: Nur die Interobjektverbindungen müssen etabliert werden, die den tatsächlichen Kommunikationsverbindungen entsprechen. Dies erweist sich bei der Modellierung von Hardware-Strukturobjekten als günstig, weil jede Objektverbindung (Port-Signale, Verbindungssignale) in der resultierenden Hardware Kosten verursacht. Kapselung von Protokollen: Besteht die Anforderung, daß Objekte über bestimmte Protokolle kommunizieren sollen, so bietet dieser Ansatz die Möglichkeit die Protokolle unabhängig von den kommunizierenden Objekten zu behandeln, indem sie den Objektverbindungen zugeordnet werden. Nutzt ein Objekt also eine solche Verbindung zur Kommunikation, wird automatisch das Protokoll der Verbindung genutzt. Insofern ist dieser Ansatz geeignet eine Trennung der Spezifikation von Objektverhalten und Kommunikationsverhalten (Protokolle) umzusetzen, wie sie in [85] gefordert und durch einige Sprachen auch umgesetzt wird (SDL, VHDL+) Weitere Aspekte Grundsätzlich ist die Frage zu stellen, ob der Mechanismus zur Kommunikation zwischen Objekten starr in eine Modellierungssprache integriert sein soll oder ob ein flexibleres Konzept, das die Einflußnahme des Anwenders auf den Kommunikationsmechanismus ermöglicht, vorzuziehen ist. Diese Frage wird für das in dieser Arbeit adressierte Anwendungsfeld später noch ausführlich diskutiert werden (vgl. Kapitel 5.4.1). Erlaubt ein Objektmodell die Spezifikation von parallelen Objekten, so ist es möglich, daß ein Server-Objekt zu einem Zeitpunkt Methodenrequests erreichen, zu dem der Server nicht bereit ist, diese zu akzeptieren. Spielt die Reihenfolge der ankommenden Methodenrequests eine Rolle, so ist es sinnvoll diese in einem Nachrichtenpuffer zwischenzuspeichern. Ist dieser Puffer als FIFO-Puffer organisiert, kann das Server-Objekt die Requests später in der Reihenfolge ihres Eintreffens aus dem Puffer auslesen und ausführen. Erlaubt das Kommunikationsmodell asynchrone Kommunikation sind Nachrichtenpuffer notwendig, um den Verlust von Nachrichten zu vermeiden. Es stellt sich jedoch die Frage nach der Anzahl von Nachrichtenpuffern aus den ein Server-Objekt Methodenrequests auslesen kann. Mehrere Nachrichtenpuffer könnten beispielsweise dann sinnvoll sein, wenn ein Objekt mehrere Ausführungsthreads besitzt und somit mehrere Methodenrequests gleichzeitig akzeptieren und ausführen kann.

27 Objektorientierte Kommunikation 15 Jedes Serverobjekt muß weiterhin eine Funktionalität zu Verfügung stellen, die ankommende Methodenrequests erkennt und im Fall der Annahme die gewünschte Methode ausführt. Ein solches Verhalten wird als Methoden- scheduling und dispatching bezeichnet und kann als Basisfunktionalität von Server-Objekten betrachtet werden. Die Anzahl der Scheduling/Dispatching Prozesse, die ein Objekt enthalten kann, charakterisiert die Anzahl der Methoden, die das Objekt gleichzeitig ausführen kann. Zu beachten ist, daß mit der Scheduling-Strategie implizit eine Aussage über die Fairneß bei der Akzeptanz von Methodenrequests gemacht wird. Beispielsweise könnten bestimmte Client-Objekte bevorzugt behandelt werden (wenn diese aus Sicht es Servers identifizierbar sind.) Viele parallele Sprachen stellen zudem noch Mechanismen zur nichtdeterministischen Auswahl von Kommunikationsrequests zur Verfügung Wiederverwendung Sowohl die Klassifikation als auch Vererbung können als Mechanismen betrachtet werden, die die Wiederverwendung von Teilen einer Implementierung ermöglichen. Zunächst können aus einer objektorientierten Klasse beliebig viele Objekte erzeugt werden. Alle Objekte besitzen dann automatisch alle Eigenschaften, die in der Klassenbeschreibung festgelegt worden sind. Um Klassendefinitionen an sich besser wiederverwenden zu können, können Klassen- Bibliotheken angelegt werden. Beim Ableiten von Klassen erbt eine Kindklasse alle Eigenschaften der Elternklasse(n). Das heißt, die Kindklasse reused sozusagen qua construktionem die Struktur und das Verhalten der Vaterklasse. Die Anwendung der objektorientierten Modellierung hat jedoch gezeigt, daß Klassenbibliotheken schnell sehr groß werden. Daher ist im allgemeinen eine geeignete Strukturierung der Bibliotheken (gegebenefalls werkzeugunterstüzt) zu empfehlen. Wird das objektorientierte Modellierungsparadigma zur Beschreibung von Hardware benutzt, so taucht zusätzlich das Problem auf, daß die Wiederverwendbarkeit einer Klasse nicht nur von deren funktionalen Eigenschaften abhängt. Beispielsweise könnte die syntheseoptimierte Modellierung einer Klasse oder deren Zeitverhalten ein entscheidendes Kriterium sein, ob diese Klasse in einem bestimmten Kontext wiederverwendbar ist. In [1] wird ein objektorientiertes Modell für den Entwurf digitaler System vorgestellt, daß

28 16 Grundlagen es erlaubt auch nichtfunktionale Anforderungen bzw. Eigenschaften in eine Klassenbeschreibung aufzunehmen.

29 Kapitel 3 Wichtige Arbeiten 3 In diesem Kapitel werden einige Sprachansätze vorgestellt, die sich im Kontext dieser Arbeit als interessant erweisen. Es ist jedoch nicht das Ziel dieses Kapitels die Ansätze im Detail zu beschreiben. Hierfür sei auf die entsprechenden Referenzen in den jeweiligen Abschnitten verwiesen. Die Konzepte der Sprachen werden nur insoweit vorgestellt, wie es für die Vorstellung der jeweiligen Kommunikationsmechanismen notwendig ist. 3.1 Formale Protokoll Sprachen Zur Modellierung von Kommunikationsprotokollen im Softwarebereich werden vielfach formale Sprachen verwendet. Im folgenden werden zwei dieser formalen Protokollsprachen vorgestellt. SDL ist eine der wohl am weitesten verbreiteten formalen Sprachen. Zusätzlich gibt es Arbeiten, die sich mit der Integration von SDL in den Hardware-Entwurfsprozeß beschäftigen. Die zweite vorgestellte Sprache ist Kannel, da Kannel einerseits objektorientiert ist und es für die Sprache eine Methodik für die Kommunikationsverfeinerung gibt SDL, SDL 92 SDL (Specification and Description Language) ist, wie es der Name schon andeutet, eine Spezifikations- und Beschreibungssprache und wird vornehmlich im Telekommunikationsbereich eingesetzt. SDL wurde ursprünglich von der CCITT, heute ITU-T, entwickelt und standardisiert. Der Standard ist beschrieben in [50]. Alle vier Jahre wird der SDL Standard überarbeitet. Im Zuge dieser Überarbeitung wurden 1992 (SDL 92) objektorientierte Erweite-

30 18 Wichtige Arbeiten rungen in die Sprache aufgenommen. Da eine vollständige, formale Semantik für SDL existiert [103], ist SDL den formalen Sprachen zuzuordnen. Die statische, hierarchische Aufteilung eines Systems erfolgt in SDL durch Blöcke. Auf der untersten Ebene der hierarchischen Zerlegung wird ein Block durch einen oder mehrere Prozesse beschrieben. Das Verhalten der SDL-Prozesse wird durch endliche Automaten (FSMs) spezifiziert. Da SDL- Prozesse asynchron kommunizieren, ist jedem Prozeß implizit ein Eingabepuffer zugeordnet, in dem neu eintreffende Nachrichten aufgenommen werden und aus dem der verarbeitende Prozeß bei Bedarf Nachrichten entnimmt. Grundsätzlich ist der Eingabepuffer als FIFO-Puffer unbeschränkter Länge organisiert. Jedoch kann ein SDL-Prozeß die FIFO-Reihenfolge der Nachrichten durchbrechen, indem bestimmte Nachrichten im Puffer gehalten werden können auch wenn diese im aktuellen Zustand nicht verarbeitet werden können (SAVE-Konstrukt). Zur Spezifikation von Zeitverhalten können jedem Prozeß eine Reihe von Timern zugeordnet werden, die vom Prozeß aufgezogen werden können. Läuft ein Timer ab, so sendet dieser dem zugeordneten Prozeß über dessen Nachrichtenpuffer eine timeout -Nachricht. Weiterhin kann die Systemzeit über die NOW -Funktion abgefragt werden. Um die Wiederverwendbarkeit von SDL-Prozessen zu verbessern, wurden symbolische Anschlüsse eingeführt (gates, ab SDL 92). Somit muß ein Prozeß zum Versenden einer Nachricht nicht mehr den Prozeßidentifikator des empfangenden Prozessen kennen. Anstatt dessen können Nachrichten direkt an einen symbolischen Anschluß geschickt werden. Der Empfänger wird durch die hierarchisch übergeordnete Verdrahtung der Prozesse bzw. Blöcke durch sogenannte Kanäle bestimmt. Da Prozesse so unabhängig von ihrer Umgebung spezifiziert werden können, können diese nun besser wiederverwendet werden. Natürlich gilt dies nur mit der Einschränkung, daß sich hierbei die zu sendenden/empfangenden Nachrichten nicht verändern. Eines der originären Anwendungsfelder von SDL ist die Spezifikation von Kommunikationsprotokollen. Hierbei haben sich die Möglichkeiten von SDL zur hierarchischen Strukturierung als besonders geeignet erwiesen, die im Telekommunikationsbereich vorherrschenden Schichtenarchitekturen von Protokollen umzusetzen. Beispiele hierfür finden sich in [35]. Durch den seit SDL 92 verfügbaren Vererbungsmechanismus, der auf dem SDL-Typsystem basiert, ist eine weitere Möglichkeit der Wiederverwendung von SDL-Code gegeben. Es ist darauf hinzuweisen, daß dieser Vererbungsmechanismus in der SDL Terminologie Spezialisierung genannt

31 Formale Protokoll Sprachen 19 wird. Alle Arten von SDL-Typen (System, Block, Process, Service, Procedure, Signal und Data) können spezialisiert werden. Schumacher [89] kommt bei seiner Betrachtung der objektorientierten Erweiterungen von SDL 92 zu dem ernüchternden Ergebnis, daß die Erweiterungen nicht geeignet sind, das Wiederverwendungsproblem für SDL im allgemeinen zu lösen. In diesem Zusammenhang wäre es sicherlich interessant zu evaluieren, ob und in wie weit die objektorientierten SDL-Erweiterungen in der Praxis angewandt werden. Dem Autor sind weiterhin keine Veröffentlichungen bekannt, in denen die objektorientierten Erweiterungen von SDL 92 zur Protokollmodellierung Anwendung finden. Im Rahmen dieser Arbeit ist SDL von zusätzlichem Interesse, da SDL eine der Spezifikationssprachen ist, deren Eignung zur Spezifikation und Implementierung von Hardware und Hardware/Software Systemen in diversen Forschungsarbeiten untersucht wurde. Die Gründe hierfür sind die folgenden: Der Entwurf von Hardware gleicht sich dem Entwurf von Software immer mehr an. Durch die Entwicklung von Hardwarebeschreibungssprachen und von hierauf basierenden Simulations- bzw. Synthesewerkzeugen ist diese Entwicklung möglich geworden. Die zustandsorientierte Beschreibungsform von SDL kommt den Hardware-Entwicklern entgegen. SDL und VHDL basieren auf dem Konzept kommunizierender Prozesse. Anmerkung: Die Kommunikationsmechanismen von VHDL und SDL Prozessen unterscheiden sich jedoch signifikant. In [40] wird ein Ansatz vorgestellt, der SDL in eine simulierbare und synthetisierbare VHDL-Beschreibung transformiert. Ein ähnlicher Ansatz wird auch in [51] beschrieben. Hier erfolgt die Übersetzung jedoch über ein Zwischenformat (SOLAR). Jedoch werden einige grundlegende Probleme durch diese Ansätze nicht gelöst: Die objektorientierten Erweiterungen von SDL 92 werden nicht unterstützt. Die in SDL verwendete asynchrone Kommunikation mit Nachrichtenpuffern unbeschränkter Länge eignet sich nur beschränkt zur Modellierung von Hardware, da unbeschränkte Nachrichtenpuffer in der Hardware nicht realisierbar sind. Die Kommunikation über Nachrichten ist im Hardwareentwurf nicht immer angemessen. Zum Beispiel erscheint es nicht als sinnvoll, daß Taktoder Rücksetzsignale als Nachrichten zwischen einzelnen Prozessen ver-

32 20 Wichtige Arbeiten schickt werden, die zudem im Nachrichtenpuffer des Zielprozesses landen. Solche Nachrichten müssen typischerweise global und gleichzeitig an alle Prozesse verschickt werden. Ein solches Broadcasting wird von SDL nicht unterstützt. Zusammenfassend kann festgestellt werden, daß die Abstraktionsmechanismen von SDL gut geeignet sind, um schichtenbasierte Kommunikationsprotokolle zu modellieren. Bei der objektorientierten SDL Erweiterung ist die Neuerung interessant, die eigentliche Funktion eines Objekts (SDL-Prozeß) von der physikalischen Schnittstelle seiner Umgebung zu trennen. Die Beschreibung der Funktion ist somit weitgehend unabhängig von der Kommunikation der Objekte. Die direkte Verwendung von SDL zur Hardware-Modellierung oder zumindest zur Modellierung von Teilaspekten von Hardware (Kommunikation) wurde durch verschiedene Arbeiten untersucht, beinhaltet aber einige grundsätzliche noch ungelöste Probleme. Leider sind dem Autor keine Arbeiten bekannt, die sich mit der Methodik des objektorientierten Entwurfs und der Verfeinerung von Kommunikationsprotokollen mit SDL 92 beschäftigen Kannel Eine weitere objektorientierte, formale Sprache, die die Modellierung von Kommunikationsprotokollen adressiert ist Kannel [41][42][43]. Kannel wurde an der Universität Helsinki entwickelt. Werkzeuge und Sprachdefinition sind verfügbar [54]. Da Kannel SDL 92 in vielen Bereichen ähnlich ist, wird auf eine Beschreibung der Sprache hier verzichtet. Jedoch weist Kannel auch einige Unterschiede zu SDL 92 auf, die eine separate Betrachtung dieses Ansatzes rechtfertigen. Kannel basiert ebenso wie SDL 92 auf dem Konzept kommunizierender Prozesse, deren Verhalten durch Zustandsautomaten beschrieben wird. Konkret werden hierfür in Kannel Statecharts von Harrel [44] benutzt. Für beide Sprachen ist sowohl eine textuelle als eine grafische Beschreibungsform definiert. Im Unterschied zu SDL 92 werden in Kannel die Mechanismen der Vererbung und der inkrementellen Verfeinerung deutlich unterschieden. Während die Vererbung in Kannel nur die Signature Compatibility nach Wegners Klassifikation [107] garantiert, gelten für die Verfeinerung strengere Anforderungen, nämlich die Behavioural Compatibility. Kannel defi-