rights / license: research collection in copyright - non ...24876/eth-24876-01.pdfrights / license:...
TRANSCRIPT
Research Collection
Working Paper
OberonT - eine Programmiersprache für sicherheitskritischeSysteme
Author(s): Schweizer, Daniel
Publication Date: 1996
Permanent Link: https://doi.org/10.3929/ethz-a-004290220
Rights / License: In Copyright - Non-Commercial Use Permitted
This page was generated automatically upon download from the ETH Zurich Research Collection. For moreinformation please consult the Terms of use.
ETH Library
OberonT � eine Programmiersprache f�ur
sicherheitskritische Systeme
Daniel Schweizer
Institut f�ur Technische Informatik und Kommunikationsnetze
ETH Z�urich� Gloriastrasse ��
CH���� Z�urich� Switzerland
TIK�Report No� ��
Version ��
September ����
Zusammenfassung
Im Rahmen des Forschungprojektes PESCA wurde ein Verfahren zur Veri�ka�tion von Programmen entwickelt� die in einer algebraischen Spezi�kationssprachebeschrieben und mit einer imperativen Programmiersprache implementiert wer�den� Bevorzugtes Anwendungsgebiet f�ur diesen Ansatz sind abstrakte Datenty�pen� die in Steuerungen von sicherheitskritischen Systemen eingesetzt werden undderen Laufzeitverhalten mit Sicherheit vorhersehbar sein muss� Als Implementa�tionssprache wird eine Teilmenge der Programmiersprache Oberon verwendet� diewir im folgenden mit OberonT bezeichen� Der vorliegende Bericht beschreibt dieEinschr�ankungen von OberonT gegen�uber Oberon und de�niert die dynamischeSemantik der Sprache unter Verwendung algebraischer Spezi�kationstechniken�Die Auswahl der zugelassenen Sprachkonstrukte erfolgt prim�ar unter dem
Gesichtspunkt der Sicherheit und in zweiter Linie unter jenem der einfachen Ve�ri�zierbarkeit� Ausgeschlossen werden insbesondere Konstrukte� welche aufgrundvon Ressourcenbeschr�ankungen zu Laufzeitfehlern f�uhren k�onnen �z�B� dynami�sche Datenstrukturen� Rekursion� und solche� deren Zeitverhalten nicht im vorausbestimmbar ist �z�B� WHILE�Schleife��Der Bericht dient als Referenz f�ur weitere Arbeiten� in denen OberonT als
Implementationssprache f�ur abstrakte Datentypen verwendet wird�
Inhaltsverzeichnis
� Einf�uhrung ���� Aufbau des Berichts � � � � � � � � � � � � � � � � � � � � � � � � �
� Sicherheitskritische Systeme ��� Interessierendes Verhalten � � � � � � � � � � � � � � � � � � � � � � �� Konsequenzen f�ur die Programmiersprache � � � � � � � � � � � � � �
� Einschr�ankungen der Sprache Oberon � �� Kontroll�uss � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � Speicherverwaltung � � � � � � � � � � � � � � � � � � � � � � � � � � �� � Seitene�ekte � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� �� Module � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � Typen � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � �� Standardprozeduren � � � � � � � � � � � � � � � � � � � � � � � � � � �� Implementation � � � � � � � � � � � � � � � � � � � � � � � � � � � � �
� Semantik der Sprache OberonT ����� Algebraische denotationelle Semantik � � � � � � � � � � � � � � � � ���� Vorgehen � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��� Signatur der konkreten Syntax � � � � � � � � � � � � � � � � � � � � ��
�� �� Kontextfreie Grammatik� Signatur � � � � � � � � � � � � ���� � Grammatik�Transformationen � � � � � � � � � � � � � � � � ���� � Signatur der konkreten Syntax � � � � � � � � � � � � � � � � ��
��� Die abstrakte Syntax von OberonT � � � � � � � � � � � � � � � � � � ���� Syntaktische Kategorien von OberonT � � � � � � � � � � � � � � � � ����� Semantische Bereiche von OberonT � � � � � � � � � � � � � � � � � ����� Fehlerbehandlung � � � � � � � � � � � � � � � � � � � � � � � � � � � ��� Semantikfunktionen � � � � � � � � � � � � � � � � � � � � � � � � � � �
����� Gleichheitsoperatoren � � � � � � � � � � � � � � � � � � � � � ����� Speichermodell � � � � � � � � � � � � � � � � � � � � � � � � ���� Ausdr�ucke �Expressions� � � � � � � � � � � � � � � � � � � � ������ Anweisungen �Statements� � � � � � � � � � � � � � � � � � � �
��� Hierarchie der Semantik�Spezi�kation � � � � � � � � � � � � � � � � �
A Syntax�Denitionen �A�� OberonT�Grammatik � � � � � � � � � � � � � � � � � � � � � � � � � �
A���� Scanner�Spezi�kation � � � � � � � � � � � � � � � � � � � � � �A��� EBNF von OberonT � � � � � � � � � � � � � � � � � � � � � � �A��� Signatur der konkreten Syntax � � � � � � � � � � � � � � � � ��
B OberonT Semantik�Spezikationen ��B�� Boolesche Algebra � � � � � � � � � � � � � � � � � � � � � � � � � � � �
B���� Semantischer Bereich � � � � � � � � � � � � � � � � � � � � � �B� Algebra ganzer Zahlen � � � � � � � � � � � � � � � � � � � � � � � � ��
B��� Semantischer Bereich � � � � � � � � � � � � � � � � � � � � � ��B�� Semantische Funktion � � � � � � � � � � � � � � � � � � � � ��B�� Diverse � � � � � � � � � � � � � � � � � � � � � � � � � � � � � ��
Kapitel �
Einf�uhrung
Im Rahmen des Forschungprojektes PESCA �DS��� wurde ein Verfahren zur Veri��kation von Programmen entwickelt� die in einer algebraischen Spezi�kationsspra�che beschrieben und mit einer imperativen Programmiersprache implementiertwerden �Sch�� Als Beispiele f�ur solche Sprachen dienen die algebraische Spezi��kationssprache LSL �GH� � und die im folgenden beschriebene Teilmenge vonOberon �Rei��� die wir mit OberonT bezeichnen� Die Auswahl der zugelassenenKonstrukte erfolgt prim�ar unter dem Gesichtspunkt der Sicherheit und in zweiterLinie unter jenem der einfachen Veri�zierbarkeit�
Die Sprache Oberon ist eine sehr kompakte� wohlde�nierte und sorgf�altig ent�worfene imperative Programmiersprache� Sie eignet sich aufgrund ihres Modul�konzepts� ihrer Einfachheit und der E�zienz ihrer Implementation ausgezeichnetf�ur die Programmierung abstrakter Datentypen� Es geht also im folgenden kei�nesfalls darum� die Sprache Oberon in irgendeiner Weise zu �verbessern�� vieleher m�ochten wir die universelle Programmiersprache durch Auszeichnung einerTeilmenge so beschr�anken� dass wir ohne die Verwendung potentiell fehleranf�alli�ger Sprachkonstrukte� auch sicherheitskritische technische Systeme realisierenk�onnen� Selbstverst�andlich geben wir damit einen Teil der M�achtigkeit der Spra�che zugunsten erh�ohter Sicherheit preis�
Es wird vorausgesetzt� dass der Leser zumindest eine algebraische Spezi�ka�tionssprache �z�B� LSL �GH� �� OBJ �GWMJ��� CIP�L �Par���� und eine Pascal��ahnliche Programmiersprache �z�B� Pascal� Modula��� Oberon �Rei��� kennt� Wirwerden im Rahmen dieses Berichtes nur einige ausgew�ahlte Aspekte von Syn�tax und Semantik der beiden verwendeten Sprachen LSL und Oberon betrachtenk�onnen�
�Wir verstehen darunter z�B� potentiell nicht terminierende Schleifen und Rekursionen sowiedynamische Datenstrukturen� die auf endlichen Speichern implementiert sind�
�
��� Aufbau des Berichts
Kapitel � erl�autert kurz einige Eigenschaften sicherheitskritischer Systeme undmotiviert anhand dieser die Verwendung einer Teilmenge der Sprache Obe�ron�
Kapitel � beschreibt die Einschr�ankungen von OberonT gegen�uber Oberon�
Kapitel � de�niert die dynamische Semantik von OberonT�
Kapitel �
Sicherheitskritische Systeme
Die Charakterisierung sicherheitskritischer Systeme ist ein �ausserst schwierigesund im Rahmen dieses Berichtes unm�oglich vollst�andig abzuhandelndes Thema�Trotzdem versuchen wir� einige Eigenschaften solcher Systeme� die im Hinblickauf eine formale Veri�kation von Bedeutung sind� zu identi�zieren und f�ur unse�re Zwecke sinnvoll auszun�utzen� F�ur weitergehende Betrachtungen wird �Rus��empfohlen�In �How�� �nden wir f�ur den Begri� safety�critical system folgende De�nition�
A computer� electronic or electromechanical system whose failuremay cause injury or death to human beings� Eg� an aircraft or nuclearpower station control system� Common tools used in the design ofsafety�critical systems are redundancy and formal methods�
��� Interessierendes Verhalten
Grunds�atzlich k�onnen wir bei sicherheitskritischen Systemen davon ausgehen�dass in der Regel das Verhalten im schlechtestm�oglichen Fall interessiert� Diesgilt sowohl f�ur den Verbrauch endlicher Ressourcen als auch f�ur das zeitlicheVerhalten� Aus diesem Grunde ist es z�B� nicht sinnvoll� in der Architektur sol�cher Systeme stochastische Elemente wie Cache�Speicher oder Prozessoren mitPipelines zu verwenden� Tats�achlich manifestiert sich diese Erkenntnis bei derArchitektur von Rechnern f�ur eingebettete Systeme �z�B� Transputer �Inm�����Analoge �Uberlegungen bei der Entwicklung von Programmiersprachen f�uhren
dazu� dass wir auf einige nicht inh�arent sichere Konstrukte der Sprache Oberonverzichten m�ochten�Es erscheint uns z�B� als sinnlos� in einem sicherheitskritischen System �
meist unter dem Titel der Abstraktion� oder einer e�zienten Berechnungsmetho�de � eine primitiv rekursive Funktion �und andere terminieren nicht in jedem
�Tats�achlich handelt es sich meist um eine unsorgf�altige Analyse des Problems�
�
Fall� mit einer WHILE� oder REPEAT�Schleife zu berechnen und anschliessend miterheblichem Aufwand zu analysieren� ob sie immer terminiert�In Bezug auf die Endlichkeit der Ressourcen Speicher und Wortl�ange muss
darauf hingewiesen werden� dass es nicht sinnvoll ist� diese inh�arenten Begrenzun�gen beim Systementwurf zu vernachl�assigen� Die Folgen solcher Vereinfachungensind komplexe Fehlerbehandlungen und Laufzeitfehler�Der Verhinderung von Laufzeitfehlern muss in jedem Fall h�ochste Priorit�at
beigemessen werden� Insbesondere bei Systemen� die keinen fail�safe Zustand�
haben� k�onnen sowohl erkannte als auch unerkannte Laufzeitfehler fatale Folgenhaben�
Sicherheit und Lebendigkeit Je nach verwendetem Spezi�kationsformalis�mus de�niert man verschiedene Formen der Begri�e Sicherheit und Lebendigkeit�siehe z�B� �Sta��� Bau��� Rei����� Wir beschr�anken uns hier darauf� die Program�miersprache so einzuschr�anken� dass folgende Eigenschaften einer Implementationveri�zierbar sind�Unter der Voraussetzung� dass ihre Vorbedingung erf�ullt ist� gelten f�ur jede
Operation des implementierten ADT folgende Aussagen�
� F�ur jede Operation kann � abh�angig von der ausf�uhrenden Maschine �eine maximale und eine minimale Zeitspanne f�ur deren Abarbeitung be�rechnet werden��
� Jede Operation gen�ugt den Axiomen und Theoremen der algebraischen Spe�zi�kation des ADT�
� F�ur jede Operation kann � abh�angig von der ausf�uhrenden Maschine �der maximale Speicherbedarf berechnet werden�
��� Konsequenzen f�ur die Programmiersprache
Bevor wir festlegen� auf welche Oberon�Sprachkonstrukte verzichtet werden soll�zitieren wir eine De�nition des Begri�s safety�critical software language aus �TM���
� � � in software engineering �programming languages�� a high�levellanguage or subset of the language that ��� has a formal syntax withwell�de�ned semantics� �� is block structured and strongly typed� and
�fail�safe state� A state of the system that cannot result in an accident� although some otherimportant goals of the system� such as availability� may be compromised �MoD��� TM���
�Wir gehen in einer ersten Betrachtung von einer defensiven Berechnung aus� d�h� beiVerzweigungen wir immer der k�urzeste l�angste� Pfad gew�ahlt� um die minimale maxima�le� Ausf�uhrungszeit zu berechnen� Durch eine Pfadanalyse w�are es m�oglich� genauere Angabenzu machen� Unsere Berechnungen sind aber in jedem Fall sicher�
�
� � is analyzable using static code analysis tools� Safety�critical soft�ware languages prohibit the use of practices that are unsafe or di�cultto analyze� such as �oating�point arithmetic� recursion �whether sim�ple or mutual�� and object code patching� Also excluded are anomaliesof �ow control such as unintended loops� unreachable code� loops withmultiple entries� and variables being used before being set or set andnot used�
�
Kapitel �
Einschr�ankungen der Sprache
Oberon
��� Kontroll�uss
Schleifen und Rekursion Um auf einfache Art und Weise garantieren zuk�onnen� dass alle Operationen des ADT in jedem Fall terminieren� schliessen wirdas WHILE ��� DO ��� END�� das REPEAT ��� UNTIL ���� und das LOOP ���
EXIT ��� END�Konstrukt sowie Rekursionen aus� Ausserdem muss die Laufva�riable der FOR�Schleife bei jedem Schleifendurchlauf inkrementiert werden� womitauch das Konstrukt ��� BY ��� entf�allt�
Direkte Rekursion wird dadurch ausgeschlossen� dass Prozeduren erst am En�de ihres procedure�body als deklariert gelten� Um indirekte Rekursion �mutual re�cursion� auszuschliessen� verzichten wir auf die forward declaration� Da zyklischeImporte ohnehin ausgeschlossen sind� entstehen auch dadurch keine Probleme�
Dieser statischen Einschr�ankung stehen �exiblere� aber sehr aufwendige Me�thoden gegen�uber� die durch Analyse eines Programms oder einer Spezi�kation�z�B� �Gri��� Sta���� versuchen� Aussagen �uber verschiedene Formen von Leben�digkeit zu machen� Diesen komplexeren Ans�atzen ist in der Praxis bisher we�nig Erfolg beschieden� Zudem garantiert eine Analyse der Spezi�kation ohne an�schliessende Veri�kation der Implementation keineswegs� dass das implementierteSystem den Anforderungen gen�ugt� Eine sichere L�osung w�are die automatischeCodegenerierung� In �Hoa��� wird aber gezeigt� dass aus einer hinreichend ab�strakten Spezi�kation im allgemeinen nur ine�zienter Code erzeugt werden kann�Eine weitere m�ogliche L�osung dieses Problems bietet die schrittweise Implemen�tation durch semantikerhaltende Transformationen �Par��� an� Leider ist auchdieses Verfahren sehr aufwendig und wird hier nicht weiter untersucht�
CASE�Anweisungen gibt es in OberonT nicht� weil das Konstrukt nicht unbe�dingt ben�otigt wird und zudem als Operator mit beliebig vielen Argumenten
�
algebraisch nur schwer beschreibbar ist��
RETURN�Anweisungen m�ussen als letzte Anweisung eines Prozedurrumpfs auf�treten�
��� Speicherverwaltung
In den zur Diskussion stehenden Systemen sind Ausnahmesituationen� die alleindurch Unzul�anglichkeiten der Steuerung entstehen� wie etwa stack over�ow odermemory allocation failed sowie stochastisches Zeitverhalten bei der Speicheral�lokation und �freigabe unerw�unscht� Die Behandlung solcher Ausnahmef�alle �sofern �uberhaupt m�oglich � kompliziert ein System in unn�otiger Art und Weise�Aus diesem Grunde unterziehen wir uns folgenden Beschr�ankungen�
Allokation von Datenstrukturen S�amtliche Datenstrukturen werden sta�tisch alloziert� Wir verzichten also auf jegliche Art von dynamischen Datenstruk�turen� In OberonT gibt es keinen Datentypen POINTER� Ein heap over�ow �memoryallocation failed� sowie Probleme mit dem Zeitverhalten durch Speicherallokati�on und �freigabe sind somit von vornherein ausgeschlossen� Damit ist auch dieKonstante NIL unn�otig�
Typerweiterung Auf die Typerweiterung �RECORD�Erweiterung� wird verzich�tet� da diese ohne die Verwendung dynamischer Datenstrukturen und dynami�scher Typen �POINTER� VAR�Parameter� wenig Sinn macht� aber die Spezi�kationder Sprach�Semantik erheblich komplizierter w�urde�� Damit sind auch die Sprach�konstrukte ��� IS ��� und WITH ��� DO ��� END unn�otig�
Stack Trotz Ausschluss von Rekursionen bleibt die Gefahr eines stack over��ows� Dieses Problem kann aber einfach gel�ost werden� indem der maximaleSpeicherbedarf f�ur den Stack statisch berechnet wird� In erster N�aherung gen�ugteine defensive Berechnung des maximalen Stack �Speicherbedarfs� bei der man aufeine Analyse von sich gegenseitig ausschliessenden Prozeduraufrufen verzichtet�Eine solche Pfadanalyse k�onnte sich allenfalls bei Massenprodukten lohnen� wosich der erh�ohte Entwicklungsaufwand durch Einsparungen beim Speicherbedarfrechtfertigen l�asst� Die Sicherheit ist aber auch bei einer defensiven Berechnungohne Pfadanalyse gew�ahrleistet�
�Es m�usste f�ur jede m�ogliche Anzahl Argumente ein separater Operator de niert werden��Dies gilt insbesondere f�ur die Spezi kationssprache LSL� welche keine Subsorten�Relation
�GM��� GWMJ�� kennt�
��
��� Seitene�ekte
Globale Variablen In OberonT schliessen wir den Gebrauch von globalen Va�riablen aus� Diese Einschr�ankung ist unbedingt n�otig� da sonst selbst grund�legendste Gesetze der Algebra� wie z�B� das Kommutativgesetz der booleschenAlgebra oder der Algebra der ganzen Zahlen nicht gelten w�urden� S�amtliche Aus�dr�ucke �expressions� bleiben damit seitene�ektfrei�
Beispiel ��� Seitene�ekte� Wir betrachten das Modul Problem aus Abbil�dung ��� Zur Illustration des Problems bedienen wir uns bereits hier der Technikder algebraischen Semantik� die in Abschnitt � vertieft behandelt wird��
MODULE Problem�
VAR a� BOOLEAN� �� Modulglobale Variable ��
PROCEDURE f���BOOLEAN�
BEGIN
a �� FALSE�
RETURN TRUE�
END f�
END Problem�
Abbildung ��� Funktion mit Seitene�ekten
Wenn wir wie in Gleichung �� davon ausgingen� dass der ��Operator vonOberon trotz Zulassung von Funktionen mit Seitene�ekten kommutativ ist� wiedies f�ur den ��Operator der booleschen Algebra gilt� so m�ussten auch die beidenAnweisungssequenzen in den Gleichungen � und � den gleichen Wert ergeben�
�b�� b � BOOLEAN� s � Store�
�� b� � b �� �s� true� �� �� b� �� �s� true� � �� b �� �s� true� � ���
�a � BOOLEAN� s � Store�
� �� a �� TRUE� RETURN�a � f��� �� �s� true�� � Bool �� true � ��
� �� a �� TRUE� RETURN�f�� � a� �� �s� true�� � Bool �� true � � �
O�ensichtlich widersprechen diese Gleichungen aber der Semantik des realenOberon�Programms� Im ersten Fall �Gleichung �� ergibt das Programm den
�Die Zeichen �� sind Bezeichner f�ur Semantikfunktionen und die Terme �s� true stehenf�ur den momentanen Speicherzustand�
��
Wert TRUE� im zweiten �Gleichung � � den Wert FALSE� Sofern wir Prozedurenmit Seitene�ekten ausschliessen� tritt das Problem in dieser Form nicht mehr auf�Ansonsten m�ussten wir die Bedeutung des ��Operators statt durch Gleichung ��durch Gleichung �� festlegen� welche besagt� dass der zweite Operand auf demdurch den ersten Operanden �evtl�� ver�anderten Speicherzustand evaluiert wird�
�b�� b � BOOLEAN� s � Store�
�� b� � b �� �s� true� �� �� b� �� �s� true� � �� b �� � �� b� �� �s� true�� � ���
�
Selbstverst�andlich w�are es mit algebraischer denotationeller Semantik m�oglich�eine Programmiersprache mit globalen Variablen zu beschreiben� Wie im obigenBeispiel gezeigt wird� h�atte dies aber zur Folge� dass die �ublichen algebraischenGesetze nicht mehr gelten� Unserer Meinung nach ist dies auch ein h�au�ger Grundf�ur die Fehlinterpretation von Programmen mit Seitene�ekten�
Prozeduren sind in OberonT immer Funktionsprozeduren und frei von Seiten�e�ekten� Wir verzichten deshalb auch auf die Verwendung von Referenzparame�tern �VAR�Parameter� und lassen daf�ur strukturierte Resultattypen zu� AndereAns�atze �Hoa�� Gan� � vermeiden Probleme mit Seitene�ekten� indem der Zu�stand des ADT nur als impliziter Parameter �modul�globale Variable� vorhandenist� Dies hat aber den Nachteil� dass es jeweils nur eine Instanz des ADT gebenkann�Da das Verhalten von OberonT�Prozeduren grunds�atzlich kontextunabh�angig
sein soll� verzichten wir auch auf verschachtelte Prozedurdeklarationen�Jeder Prozedurrumpf muss als letzte Anweisung explizit einen RETURN�Wert
zur�uckgeben�
��� Module
Das Modul SYSTEM darf nicht importiert werden�
�� Typen
Wir verzichten auf folgende Oberon�Typen�
� POINTER
� PROCEDURE
� LONGREAL REAL
�
� LONGINT SHORTINT
� SET
�� Standardprozeduren
Wir verzichten auf folgende Standardprozeduren�
� ENTIER� LONG� SHORT �Typkonversionen�
� NEW �Speicherallokation�
� COPY �Kopieren von Zeichenketten mit VAR�Parameter�
� EXCL� INCL �SET � Operationen�
� INC� DEC �INTEGER � Operationen mit VAR�Parametern�
��� Implementation
Die Syntax�Analyse f�ur unser experimentelles System wurde mit GIPSY �Hel��Mar��� implementiert� Basierend auf erweiterbaren attributierten Grammatiken�Mar��� erlaubt dieses Werkzeug die Erweiterung des front�end zu Veri�kations�zwecken �Sch�� F�ur die Codegenerierung ben�utzen wir vorderhand einen Standard�Oberon���Compiler� wobei wir
� bei der Verwendung von FOR�Schleifen auf die Einhaltung der dynamischenSemantik gem�ass Abschnitt ����� achten�
� strukturierte R�uckgabewerte mit Hilfe von Zeigervariablen simulieren� in�dem wir innerhalb des Prozedurrumpfs Speicherplatz f�ur den R�uckgabewertallozieren und den tats�achlich zur�uckgebenen Zeiger sofort nach Abarbei�tung der Funktionsprozedur dereferenzieren�
Der Entscheid� f�ur die Codegenerierung vorderhand einen Standard�Oberon���Compiler zu ben�utzen� ist rein pragmatischer Natur und liegt darin begr�undet�dass dessen Neu�Implementation einen erheblichen Aufwand mit sich bringt�
�
Kapitel �
Semantik der Sprache OberonT
��� Algebraische denotationelle Semantik
Die algebraische denotationelle Semantik � �GPG��� SK�� BHK��� ist eine for�male Methode zur Beschreibung der Semantik von Programmiersprachen� Dabeiordnen Semantikfunktionen� die durch semantische Gleichungen de�niert sind�jedem g�ultigen Satz der Programmiersprache eine Bedeutung aus den semanti�schen Bereichen zu� Syntaktische Kategorien bezeichnen Mengen von syntakti�schen Objekten der Sprache �z�B� Ausdr�ucke� Anweisungen etc�� und werden ausder abstrakten Syntax � abgeleitet� Semantische Bereiche sind ��Algebren� derenEigenschaften durch entsprechende algebraische Spezi�kationen festgelegt sind�Semantikfunktionen sind somit Abbildungen von syntaktischen Kategorien in se�mantische Bereiche�
Im Rahmen der formalen Sprachde�nition betrachten wir ausschliesslich diedynamische Semantik von OberonT� Diese spezi�ziert das Laufzeitverhalten ei�nes g�ultigen Programms� w�ahrend die statische Semantik festlegt� wann ein Pro�gramm g�ultig ist� Die statische Semantik befasst sich demnach mit Aspekten wieDeklarationsanalyse und Typkorrektheit und ist nicht Thema dieses Berichts�Wir gehen bei der Spezi�kation der dynamischen Semantik stets davon aus� dassein g�ultiges OberonT�Programm vorliegt� Die statische Semantik entspricht bisauf erw�ahnte Ausnahmen jener von Oberon�
Die Einfachheit der Implementationssprache und ihrer Semantik ist ein wich�tiges Kriterium� auf das wir in der Folge gr�ossten Wert legen� Es zeigt sich�dass die De�nition einer formalen Semantik dazu beitr�agt� die Programmier�sprache so kompakt wie m�oglich zu halten� ohne dass dies f�ur den Anwenderbedeutende Unannehmlichkeiten mit sich bringt� So k�onnen wir z�B� durch dieEinschr�ankung� dass RETURN�Anweisungen nur am Ende eines Prozedurrumpfs
�Statt von algebraischer denotationeller Semantik spricht man oft auch einfach von alge�
braischer Semantik �SK����siehe Abschnitt ���
��
vorkommen d�urfen� auf die Einf�uhrung von continuations� verzichten� Indem wirvon R�uckspr�ungen aus Verzweigungen� Schleifen und beliebigen Schritten einerAnweisungssequenz absehen� erhalten wir einerseits besser lesbare Programmeund vereinfachen andererseits die Spezi�kation�Die Semantik der Programmiersprache ist durch eine Hierarchie von algebrai�
schen Spezi�kationsmoduln �LSL�traits� gegeben� Eine algebraische Spezi�kationin der Sprache LSL besteht im wesentlichen aus f�unf Bl�ocken�
Titelblock Der Titelblock de�niert den Namen und die Parameter des Spezi��kationsmoduls� Ein Spezi�kationsmodul wird als trait bezeichnet�
Importblock Der Importblock �includes ��� � listet die importierten Spezi��kationsmodule auf und instanziert deren Parameter� Die includes�Relationist transitiv�
Signaturblock Der Signaturblock �introduces ��� � de�niert Operatoren undSorten und damit die Syntax der Schnittstelle des spezi�zierten ADT�
Axiomenblock Der Axiomenblock �asserts ��� � spezi�ziert die Semantikder Operatoren�
Theoremblock Im Theoremblock �implies ��� � �nden wir die Theoreme�welche aufgrund der Semantik der Operatoren gelten sollten� Diese Theo�reme dienen der semantischen Untersuchung der Spezi�kation� Sie m�ussenaus den Axiomen herleitbar sein�
Eine detaillierte Einf�uhrung in die Spezi�kationssprache LSL �ndet man in �GH� ��F�ur eine formale De�nition der Semantik algebraischer Spezi�kationen verweisenwir auf die einschl�agige Literatur �GH��� GTW��� PBB��� EGL��� Wir����
��� Vorgehen
Wir de�nieren die algebraische denotationelle Semantik von OberonT in folgendenSchritten�
�� Die Grammatik�De�nition von Oberon enth�alt Iterationen� Optionen undAlternativen� die nicht direkt auf eine Signatur einer algebraischen Spezi��kation abbildbar sind�� Sie wird deshalb einer geeigneten Transformationunterzogen� Ausserdem ben�otigen wir f�ur die Implementation von Werk�zeugen mit GIPSY �Hel�� eine LL����Grammatik� so dass z�B� auch Links�rekursionen eliminiert werden m�ussen�
�Continuations sind semantische Bereiche� mit deren Hilfe die Bedeutung von Anomalien desKontroll�usses� wie z�B� GOTO� oder RETURN�Anweisungen� beschrieben werden �SK��� All���
�siehe Abschnitt �����
�
� Aus der transformierten Grammatik erzeugen wir die Signatur der konkre�ten Syntax von OberonT�
� Ausgehend von der Signatur der konkreten Syntax� de�nieren wir diejenigeder abstrakten Syntax�
�� Die syntaktischen Kategorien ergeben sich aus den Sorten der Signatur derabstrakten Syntax�
� Die semantischen Bereiche k�onnen unabh�angig von den bisherigen Schrittenspezi�ziert werden�
�� Mit Hilfe der semantischen Funktionen wird den syntaktischen Konstruktenihre Bedeutung im semantischen Bereich zugeordnet� An dieser Stelle wirdauch die Fehlerbehandlung vorgenommen� indem die Funktionen partiellsind�
In den folgenden Abschnitten werden die einzelnen Schritte der Semantik�De�nitiongenauer betrachtet�
��� Signatur der konkreten Syntax
����� Kontextfreie Grammatik � Signatur
Jeder kontextfreien Grammatik G � hN� T� s�� P i kann eine Signatur ��G� �hS��i wie folgt zugeordnet werden�
�� Die Sorten sind gegeben durch S � N �
� Die Operatoren ergeben sich folgendermassen�
� F�ur jede Produktion n � t� mit t � T � n � N � de�nieren wir einenOperator t �� n�
� F�ur jede Produktion n � n� � � � nk� mit n � N � n� � � � nk � N�� de��nieren wir einen Operator n � n�� � � � � nk � n�
Man beachte� dass die meisten Grammatik�De�nitionen in EBNF beschriebensind� Um die obigen Regeln anwendbar zu machen� m�ussen solche Beschreibungenzuerst einer geeigneten Transformation unterzogen werden� so dass sie nur nochProduktionen der Form n� n� � � � nk und n� t enthalten�
��
����� Grammatik�Transformationen
Mit Hilfe der Regeln gem�ass Tabelle ��� erzeugen wir aus der eingeschr�anktenOberon�Grammatik eine LL����Grammatik� aus welcher direkt die Signatur derkonkreten Syntax abgeleitet werden kann� Die Regeln werden auf alle Produktio�nen rekursiv so lange angewendet� bis keine Transformation mehr m�oglich ist� Inder Grammatik gem�ass Anhang A��� wurden Alternativen und Optionen nochnicht eliminiert und die Terminal�Symbole noch nicht extrahiert�
Ziel ProduktionenOriginal transformiert
Extraktion von Terminal�Symbolen x� mtn x� mkn
k � t
Elimination von Iterationen x� mfng x� mk
k � �nk�Elimination von Alternativen x� m�n� j n�� x� mn�
x� mn�Elimination von Optionen x� m�n� x� mn
x� m
Elimination von Linksrekursionen x� m j xn x� mfngx� m j xnm x� mfnmgx� mfnmg x� m�nx�x� m j xn�m� x� m�n�x��
x�m� n� n�� n�� k� Nichtterminal�Symbole t� Terminal�Symbol
Tabelle ���� Grammatik�Transformationen
����� Signatur der konkreten Syntax
Als Beispiel betrachten wir an dieser Stelle die erste Produktion der OberonT�Grammatik gem�ass Anhang A����
Module ��� �MODULE� Ident ��� DeclSeq� �END� ident ���
Module ��� �MODULE� Ident ��� �IMPORT� Import Imports ���
DeclSeq� �END� ident ���
wird in folgende Signatur abgebildet�
module� Ident� DeclSeq�� Ident � Module
module� Ident� Import� Imports� DeclSeq�� Ident � Module
ident� � Ident � Extraktion des TerminalSymbols ident�
Man k�onnte die Schl�usselw�orter wie die anderen Terminal�Klassen behandeln� dasie aber f�ur die Semantik�De�nition nicht von Bedeutung sind� lassen wir sie inder Signatur weg�
��
Die vollst�andige Signatur der konkreten Syntax von OberonT �ndet man inAnhang A��� �
��� Die abstrakte Syntax von OberonT
Im Gegensatz zur konkreten Syntax abstrahiert man bei der abstrakten Syntaxeiner Sprache von s�amtlichen Details� welche ausschliesslich f�ur die syntaktischeAnalyse �parsing� ben�otigt werden �SK��� Dadurch wird die Beschreibung bedeu�tend kompakter und enth�alt nur noch Informationen� welche f�ur die Untersuchungder Semantik von Interesse sind� Die abstrakte Syntax einer Sprache ist nicht ein�deutig de�niert� Sie kann somit der angewendeten Technik zur Beschreibung derSemantik und dem untersuchten Aspekt angepasst werden�
Abbildung ��� zeigt die Signatur der abstrakten Syntax von OberonT� Siebesteht aus den syntaktischen Konstrukten� deren Bedeutung wir festlegen m�och�ten�� Der Parameter SynCat kann mit einer beliebigen syntaktischen Kategorieinstanziert werden�
AbstractSyntax�SynCat��trait
includes
DecimalLiterals�INTEGER for N�
introduces
TRUE�FALSE�� BOOLEAN
� j � �� � � �BOOLEAN�BOOLEAN � BOOLEAN
� �BOOLEAN � BOOLEAN
�INTEGER � INTEGER
� � � � �DIV�MOD�INTEGER�INTEGER � INTEGER
� � �� � � � �� � �� � � �INTEGER�INTEGER � BOOLEAN
� �Stmt�Stmt � Stmt
� IF THEN ELSE END�BOOLEAN�Stmt�Stmt � Stmt
IfThenElse�BOOLEAN�Stmt�Stmt � Stmt
� FOR �� TO DO END�INTEGER�INTEGER�INTEGER�Stmt � Stmt
LOOP�INTEGER�INTEGER�INTEGER�Stmt � Stmt
RETURN�SynCat � Stmt
�� �SynCat�SynCat � Stmt
�� � � �SynCat�SynCat � BOOLEAN
Abbildung ���� Signatur der abstrakten Syntax von OberonT
�Der Oberon�Gleichheitsoperator ��� ist in allen LSL�traits mit ���� oder ���� bezeichnet�damit er vom LSL�Gleichheitsoperator ��� unterscheidbar ist siehe auch Abschnitt �������
��
�� Syntaktische Kategorien von OberonT
Da wir bei der Veri�kation von Programmen Verhaltens�aquivalenzen untersuchen�welche durch typisierte Gleichungen de�niert sind� unterscheiden wir bereits beider abstrakten Syntax zwischen Ausdr�ucken mit verschiedenen Resultattypen�Dies f�uhrt dazu� dass sich die Menge der syntaktischen Kategorien aus einem kon�stanten Teil f�ur Anweisungen und Ausdr�ucke in Basistypen und einem variablenTeil mit Ausdr�ucken in neu deklarierten Typen zusammensetzt� Wir betrachtenalso die Deklaration neuer Typen als eine Erweiterung der Sprache�Ein OberonT�Programm wird durch folgende syntaktische Kategorien model�
liert�
Stmt � Anweisungen
BOOLEAN � boolsche Ausdr�ucke
INTEGER � Ausdr�ucke mit ganzen Zahlen
Bezeichner werden als Ausdr�ucke des entsprechenden Typs interpretiert� F�ur je�den neu deklarierten Typen Type wird diese Menge um die syntaktische KategorieType erweitert� Strukturierte Typen �Records und Arrays� werden in die seman�tischen Bereiche Record bzw� Array abgebildet� F�ur jeden deklarierten Record �Typen RecType wird eine syntaktische Kategorie RecType Fld eingef�uhrt� in derdie Namen der entsprechenden Record �Felder enthalten sind�
�� Semantische Bereiche von OberonT
Wir verwenden in unserer De�nition folgende semantische Bereiche�
Bool � boolsche Werte �Anhang B�����
Spezi�ziert die �ublichen Operationen einer booleschen Algebra� Zu ihrenTheoremen geh�oren auch Gleichungen aus anderen traits �AC� Distributive�Involutive� Transitive�� die in �GH� � n�aher erl�autert sind�
Int � ganze Zahlenwerte �Anhang B����
Die Zahlen�Algebra wurde so spezi�ziert� dass die Darstellung jeder Zahlgenau eine Normalform hat und dass aus den Gleichungen ein e�zien�tes Termersetzungssystem erzeugt werden kann� welches die Relationen���� ��� f�ur jedes Zahlenpaar automatisch entscheidet� Die Spezi�kati�on in Anhang B��� ist deshalb verschieden von jener in �GH� ���
�Das mit LP Standardeinstellungen� erzeugte Termersetzungssystem f�ur den Integer�trait aus �GH�� reduziert z�B� den Term � � �� bzw� sss���� � sssss������ nicht ohneBenutzer�Interaktion zu true�
��
Array � Array�Werte �Abb� ���
Die Standard�Spezi�kation f�ur Arrays wurde um die Operatoren newA� �Array und assNF� Array Int SV � Array f�ur die Darstellung einesleeren Arrays resp� eines Arrays in Normalform erweitert� Die Einf�uhrungeiner Normalform reduziert die mittlere L�ange der Terme� die im Lau�fe eines Beweises entstehen� und beschleunigt dadurch dessen maschinelleAusf�uhrung�
Array�Array�Int��trait
includes
Int�Int�
introduces
newA�� Array
assNF�Array�Int�SV � Array
assign�Array�Int�SV � Array
� ��Array�Int � SV
asserts
Array generated freely by newA�assNF
Array partitioned by � �
�a�Array�v�w�sv�SV�i�j�IntassNF�a�i�v��j� �� if i � j then v else a�j��
assign�a�i�v��j� �� if i � j then v else a�j��
assign�newA�i�v� �� assNF�newA�i�v��
assign�assNF�a�i�v��j�w� ��
if i � j then assNF�a�i�w�
else
if i � j then assNF�assign�a�j�w��i�v�
else assNF�assign�a�i�v��j�w��
assign�assign�a�i�v��j�w� ��
if i � j then assNF�a�i�w�
else
if i � j then assNF�assign�a�j�w��i�v�
else assNF�assign�a�i�v��j�w��
implies
converts
assign�
� � exempting �i�Int newA�i�
Abbildung ��� Algebraische Spezi�kation f�ur Array�Werte
Field � Namen von Record �Feldern �Abb� �� �
Record � Record �Werte �Abb� �� �
�
Die Spezi�kation f�ur die Darstellung von Record �Werten gleicht jener f�urArrays� ausser dass die Indizes Bezeichner f�ur die Record �Felder anstattganze Zahlen sind� Auch hier wurde zur Reduktion der mittleren Terml�angeeine Normalform eingef�uhrt�
Record�R�Field��trait
introduces
newR�� R
setNF�R�Field�SV � R
set�R�Field�SV � R
� �R�Field � SV
asserts
R generated freely by newR�setNF
R partitioned by �
�r�R�g�h�Field�v�w�SVset�r�g�v��h �� if g � h then v else r�g�
setNF�r�g�v��h �� if g � h then v else r�g�
set�newR�g�v� �� setNF�newR�g�v��
set�setNF�r�g�v��h�w� ��
if g � h then setNF�r�g�w�
else setNF�set�r�h�w��g�v��
set�set�r�g�v��g�w� �� set�r�g�w��
implies
converts
set�
� exempting �g�Field newR�g
Abbildung �� � Algebraische Spezi�kation f�ur Record �Werte
Loc � Adressen im Speicher �Abb� ���
Store � Speichermodell �Abb� ����
Der Speicher wird als eindimensionales Array mit Normalformdarstellung�siehe Array� modelliert� wobei alle im System vorkommenden Bezeichnerf�ur Variablen als Indizes dienen und die gespeicherten Werte �ParameterSV� beliebige Instanzen einfacher oder strukturierter Typen sein k�onnen�
M � Speicher mit G�ultigkeits�Indikator f�ur die Fehlerbehandlung �Abb� ���
Erweiterung von Store�
Wir verzichten auf die Einf�uhrung eines semantischen Bereichs Environment� indem die Bindung von Bezeichnern f�ur Variablen und Prozeduren an Adressen
�siehe Abschnitt ���
�
Store�Store�Loc�SV��trait
introduces
new�err�� Store
putNF�Store�Loc�SV � Store
put�Store�Loc�SV � Store
� ��Store�Loc � SV
asserts
Store generated freely by err�new�putNF
Store partitioned by � �
�s�Store�i�j�Loc�v�w�SVputNF�s�i�v��j� �� if i � j then v else s�j��
put�new�i�v� �� putNF�new�i�v��
put�putNF�s�i�v��j�w� ��
if i � j then putNF�s�i�w�
else putNF�put�s�j�w��i�v��
implies
converts
put�
� � exempting
�i�Loc new�i��err�i�
Abbildung ���� Algebraische Spezi�kation f�ur den Speicher
im Speicher de�niert wird� Da wir auf die Verwendung von dynamischen Da�tenstrukturen� Prozedurvariablen und Adressarithmetik verzichten� bietet dieseVereinfachung keine Probleme� bringt aber den Vorteil mit sich� dass die sp�aterzu untersuchenden Terme k�urzer werden�Bezeichner f�ur Prozeduren werden durch semantische Gleichungen an eine
Folge von Anweisungen gebunden�
��� Fehlerbehandlung
Einige der nachfolgend eingef�uhrten Semantikfunktionen de�nieren die Bedeu�tung von syntaktischen Objekten� bei deren Evaluation Laufzeitfehler auftretenk�onnen� Trotzdem die Verhinderung solcher Fehler eines der wichtigsten Ent�wurfskriterien von OberonT ist� sind prinzipiell folgende F�alle m�oglich�
� INTEGER�over�ow � �Uberschreitung des Bereichs der ganzen Zahlen�
� INTEGER�under�ow � Unterschreitung des Bereichs der ganzen Zahlen�
� INTEGER�division�by�zero� Division durch Null bei ganzen Zahlen�
� ARRAY�over�ow � �Uberschreitung der Bereichsgrenzen eines Arrays�
� ARRAY�under�ow � Unterschreitung der Bereichsgrenzen eines Arrays�
Die letzten drei Fehler k�onnten durch ein Verbot der INTEGER�Division bzw� denVerzicht auf Arrays von vornherein ausgeschlossen werden � beides w�aren abernach unserer Ansicht zu starke Einschr�ankungen� Die INTEGER�Division wirdf�ur den Umgang mit physikalischen Gr�ossen �Berechnung von Geschwindigkei�ten� Beschleunigungen etc�� ben�otigt� w�ahrend Arrays der Repr�asentation vonDatenstrukturen dienen� Eine andere M�oglichkeit Laufzeitfehler zu verhindern�welche auf Bereichs�uberschreitungen zur�uckzuf�uhren sind� w�are die Verwendungvon endlichen Zahlenk�orpern statt des Bereichs der ganzen Zahlen� Man k�onntedann z�B� de�nieren� dass MAXINT � � MAXINT oder MAXINT � �MININT gilt� Diese Semantik entspr�ache jener der realen Implementation aufeinem Computer mit endlichen Ressourcen� Der Programmierer muss sich derEndlichkeit der darstellbaren Zahlen in jedem Fall bewusst sein und sie in denSystementwurf miteinbeziehen� �Abstrahiert� er von dieser Gegebenheit� bestehtdie Gefahr� dass beim Einsatz des Programmes Laufzeitfehler auftreten�Um solche Probleme bei der symbolischen Untersuchung eines ADT aufzu�
decken� wird der SpeicherM durch ein PaarM � Store�Bool modelliert� wobeider boolesche Wert angibt� ob die Evaluation eines Ausdrucks oder einer An�weisung durch die Semantikfunktion einen g�ultigen Wert ergeben hat� Falls dieBedeutung eines syntaktischen Konstrukts in einem bestimmten Kontext einenfehlerhaften Speicherzustand ergibt� ist das Resultat aller darauf angewandtenSemantikfunktionen unde�niert� Das bei der Veri�kation eingesetzte Termerset�zungssystem� kann deshalb die entstehenden Terme nicht weiter reduzieren� wo�durch der Korrektheitsbeweis blockiert wird�Indem wir die Fehlerdetektion bei der Auswertung der Semantikfunktionen
vornehmen� bleiben die Spezi�kationen der semantischen Bereiche so einfach wiem�oglich� Trotzdem erkennen wir potentielle Probleme w�ahrend der Veri�kationund k�onnen ein Termersetzungssystem erzeugen� das Terme� in denen ein ung�ulti�ger Speicherzustand auftritt� nicht weiter reduziert� Damit ist es auch verh�alt�nism�assig einfach� einen Fehler zu lokalisieren�Eine andere M�oglichkeit der Fehlerbehandlung best�unde darin� jeden semanti�
schen Bereich um ein Fehlerelement zu erweitern� Der Nachteil dieser Methodebesteht darin� dass die Einf�uhrung solcher Fehlerelemente bei Algebren eine star�ke Zunahme der Anzahl und Komplexit�at der Gleichungen zur Folge hat unddie Gefahr von inkonsistenten Spezi�kationen zunimmt �GTW���� Zudem w�urdedie Reduktion von fehlerhaften Termen auf das Element die Lokalisierung vonFehlern wesentlich erschweren�Eine elegantere Fehlerbehandlung erlauben order�sorted algebras �GM���
�GWMJ��� bei denen Sorten in eine partielle Ordnung von Untersorten auf�geteilt und kritische Operationen nur auf den entsprechenden Untersorten de��niert werden� Beispielsweise l�asst sich die Sorte Nat in die Untersorten Nat �
NzNat� Zero aufteilen�NzNat ist dann die Sorte f�ur die nat�urlichen Zahlen ohne
� und Zero jene f�ur �� Die Division hat die Signatur DIV � Nat�NzNat � Nat
und ist somit ausschliesslich f�ur Divisoren de�niert� die verschieden von � sind�Wir verzichten auf die Anwendung von order�sorted algebras� weil das verf�ugba�re Termersetzungssystem OBJ� die Spezi�kationen ausschliesslich auf der Basisinitialer Algebra Semantik interpretiert�
��� Semantikfunktionen
Wir f�uhren drei verschiedene Semantikfunktionen ein�
�� �� � SynCat� M � SemDom
f�ur die Bedeutung von Bezeichnern �Identi�ers� und Ausdr�ucken �Expressions�auf dem momentanen Speicherzustand� Diese Klasse von Semantikfunktionenwird f�ur jeden Datentypen instanziert �z�B� mit SynCat BOOLEAN� SemDom Bool��
�� �� � Stmt� M� M
f�ur die Bedeutung von Anweisungen �Statements� und
�� �� � Stmt� M� SemDom
f�ur die Bedeutung von Funktionsprozeduren bzw� der RETURN�Anweisung� Auchdiese Signatur beschreibt eine Klasse von Semantikfunktionen� die je nach Da�tentyp des R�uckgabewertes instanziert wird �z�B� mit SemDom Int��Ausgehend vom Speichermodell beschreiben wir mit Hilfe dieser Semantik�
funktionen die Bedeutung der OberonT�Sprachkonstrukte�
����� Gleichheitsoperatoren
Im Rahmen der Semantik�Spezi�kation und auch sp�ater bei der Veri�kation tre�ten vier verschiedene Gleichheitsoperatoren auf� deren Bedeutung hier n�aher be�trachtet werden soll�
��� tritt als Vergleichsoperator sowohl in der Oberon� als auch in der LSL�Syntaxauf�
� Der Oberon�Vergleichsoperator hat die Bedeutung� welche ihm durchdie Semantikfunktionen zugeordnet wird� Damit er in den LSL�traitsvom LSL�Gleichheitsoperator unterscheidbar ist� bezeichnen wir ihndort mit !��" oder mit !��"�
� Die Bedeutung des LSL�Gleichheitsoperators ist eine Kongruenz aufder Termalgebra�
�
����� ���� ist eine Umbenennung f�ur den Oberon�Vergleichsoperator �siehe !�"��
���� hat die gleiche Bedeutung wie der LSL�Gleichheitsoperator !�"� bindet aberschw�acher als dieser� d�h� a � b �� c � d ist identisch mit �a � b� ��
�c � d��
��� ist die Kongruenz auf Oberon�Termen� welche durch die Verhaltens�aquiva�lenz de�niert wird�
Zwischen den einzelnen Operatoren gelten folgende Beziehungen�
�t�� t � SynCat� s � Store�
�s � Store� �� t� �� �s� true� � �� t �� �s� true�� t� � t �����
�t�� t � SynCat� s � Store�
t� � t� �s � Store� �� t� �� �s� true� � �� t �� �s� true� ����
�t�� t � SynCat� s � Store�
�� t� �� t �� �s� true� �� �� t� �� �s� true� � �� t �� �s� true� ��� �
F�ur die Implikation ��� gilt die Umkehrung im allgemeinen nicht� weil beispiels�weise zwei identische Mengen durch verschiedene Arrays repr�asentiert werdenk�onnen� Die Arrays w�aren in diesem Fall verhaltens�aquivalent� aber nicht gleich�Implikation �� ist im allgemeinen nicht umkehrbar� da zwei identische Werteauch von verschiedenen Bezeichnern referenziert werden k�onnen�
����� Speichermodell
Einfache Speicherzugri�e �Abb� ��� bilden wir auf eindimensionale Array�Zugri�e ab� Die Hilfsfunktionen sv� SemDom � SV und deren Inverse val�SV � SemDom werden ben�otigt� damit Werte jedes beliebigen Typs in denSpeicher geschrieben bzw� vom Speicher gelesen werden k�onnen �Typkon�version��
Speicherzugri�e bei Arrays �Abb� ����
Das Lesen von Daten aus strukturierten Typen bietet keine besonderenProbleme� Schwieriger ist hingegen die Beschreibung der Semantik von Zu�weisungen� Wir stossen dabei auf folgende Probleme�
�Die algebraische Spezi kation eines abstrakten Datentypen kann Verhaltens�aquivalenzen
spezi zieren� indem sie Mengen von Operatoren auf einer Sorte als sogenannte Beobachtungs�
operatoren Observer� auszeichnet� Zwei Terme der beobachteten Sorte gelten als gleich� wennsie durch die Applikation aller Beobachtungsoperatoren der entsprechenden Sorte nicht vonein�ander unterscheidbar sind� Wir nennen sie dann verhaltens�aquivalent�
Storable�SynCat�SemDom��trait
includes
Store�Store�Loc�SV��
VariableId�Loc��
AbstractSyntax�SynCat�
M tuple of store�Store�valid�Bool
introduces
sv�SemDom � SV
val�SV � SemDom
adr�SynCat � Loc
��SynCat � SynCat
�� �� �SynCat�M � SemDom
�� �� �Stmt�M � M
�� �� �Stmt�M � SemDom
�� �� �BOOLEAN�M � Bool
� �SynCat�SynCat � Bool
�� �BOOLEAN�Bool � Bool
asserts
SV partitioned by val�SV � SemDom
SemDom partitioned by sv�SemDom � SV
�s��s��Stmt�t��t��SynCat�s�Store�b�BOOLEAN�v��SemDom�b��SV
val�sv�v��� �� v��
sv�val�b��� �� b��
�� t�� �� t� �� �s�true� ��
�put�s�adr�t���sv� �� t� �� �s�true����true��� �� s�� s� �� �s�true���SemDom ��
� �� s� �� � �� s� �� �s�true���M��SemDom��� t�� �� �s�true� ��
if s �� new then val�s�adr�t���
else �� t�� �� �err�false���� RETURN�t�� �� �s�true� �� �� t� �� �s�true����s� �� b �� �s�true� ��
� �� t� �� �s�true� � �� t� �� �s�true���� �� �b �� �t� � t����
��s� �� t� �� �s�true� � �� t� �� �s�true��� �� �t� � t���
�t� � t�� �� �s� �� t� �� �s�true� � �� t� �� �s�true���
Abbildung ��� Semantikfunktionen f�ur einfache Speicherzugri�e
�
�� In OberonT ist die Zuweisung von ganzen Strukturen m�oglich� Da wirin unserem Modell von der konkreten Berechnung von Adressen imSpeicher abstrahieren� m�ussen wir einen anderen Weg �nden� um Zu�weisungen an ein Array so abzubilden� dass sowohl Zugri�e auf dieganze Struktur als auch auf Teile davon auf einfache Art und Weisem�oglich sind�
� Wie Abbildung ��� zeigt� k�onnen Designatoren� beliebig komplex auf�gebaut sein�
TYPE
Data � RECORD
f�� BOOLEAN�
f�� ARRAY �� OF INTEGER�
END�
Column � ARRAY ��� OF Data�
Field � ARRAY ��� OF Column�
PROCEDURE Assign������
VAR
r� Column�
f�g� Field�
d� Data�
i�j� INTEGER�
BEGIN
���
�� ganzes zweidimensionales Array zuweisen ��
g �� f�
�� einzelnes Feld der Struktur zuweisen ��
�� � �� g���i��i�j��f��k� �� ���i�j��
�� ganzes eindimensionales Array zuweisen
�Teil der Struktur� ��
g���i�� �� r�
���
Abbildung ���� Zuweisungen an strukturierte Typen
Wir l�osen diese Probleme folgendermassen�
�� Strukturierte Typen werden als gekapselte Objekte modelliert� die alsGanzes wie unstrukturierte Werte zu behandeln sind� Die Zuweisungan einzelne Teile der Struktur erfolgt gem�ass den Erl�auterungen unterPunkt ����
Bezeichner f�ur linke Seiten der Zuweisung
�
� Zuweisungen an komplexe Designatoren werden in eine Sequenz voneinfachen und eindimensionalen Zuweisungen zerlegt� Als eindimen�sional bezeichnen wir Zuweisungen von der Form
Assignment ��� Designator ���� Expression
Designator ��� ident ���� ident � ��� Expression �����
Dazu f�uhren wir f�ur jeden strukturierten Typen eine von aussen nichtsichtbare Variable � h� ein� Komplexe Designatoren werden von rechtsnach links analysiert� indem wir feststellen� ob es sich um eine Zuwei�sung an ein Array� �endet mit �Index�� oder ein Record �Feld �endetmit �Feldname� handelt� Abbildung ��� zeigt anhand eines Beispiels�wie eine komplexe Zuweisung modelliert wird�
�� g���i��i�j��f��k� �� ���i�j� �� �s�true� �� ��h�Data f� Type �� g���i��i�j��f�� � einfache Zuweisung
h�Data f� Type�k� �� ���i�j�� � eindimensionale Zuweisung
g���i��i�j��f� �� h�Data f� Type� � neue komplexe Zuweisung
h�Data �� g���i��i�j� � einfache Zuweisung
h�Data�f� �� h�Data f� Type� � eindimensionale Zuweisung
g���i��i�j� �� h�Data� � neue komplexe Zuweisung ���
h�Column �� g���i��
h�Column�i�j� �� h�Data�
g���i� �� h�Column�
h�Field �� g�
h�Field���i� �� h�Column�
g �� h�Field �� �s�true� � ��� einfache Zuweisung
Abbildung ���� Semantik der Zuweisung �� aus Abb� ���
Speicherzugri�e bei Records �Abb� ���� werden analog zu jenen bei Arraysmodelliert� ausser dass die Indizes Bezeichner f�ur die Record �Felder anstattganze Zahlen sind�
����� Ausdr�ucke Expressions
Boolesche Ausdr�ucke �Abb� ����� werden in der zu erwartenden Art und Wei�se auf den semantischen Bereich Bool abgebildet� Da wir Seitene�ekte aus�schliessen� ergeben sich hier keine Probleme� Ansonsten m�ussten die Glei�chungen entsprechend den Erl�auterungen in Abschnitt � modi�ziert wer�den�
�
ARRAY OF Type�ARRAY OF Type�len Type�SynCat�SemDom��trait
includes
Array�Array�Int��
INTEGER�
Storable�ARRAY OF Type�Array��
Storable�SynCat�SemDom�
introduces
� ��ARRAY OF Type�INTEGER � SynCat
h�� ARRAY OF Type
len Type�� INTEGER
asserts
�s�Store�a�Loc�v�SV�b�SynCat�n�INTEGER�t�t��ARRAY OF Type�b��Bool
� Zugriff auf ganzen Array�in Storable geregelt
� Zugriff auf ein Feld�
�� t�n� �� �s�true� ��
if s �� new
� inRange��� �� n �� �s�true�� �� len Type �� �s�true� �� then
val�� �� t �� �s�true�� � � �� n �� �s�true�� �
else �� t�n� �� �err�false��� Zuweisung ganzer Array�in Storable geregelt
� Zuweisung einzelner Felder�
� h �� t� h�n� �� b� t �� h
� �� t�n� �� b �� �s�true���M ��
if inRange��� �� n �� �s�true�� �� len Type �� �s�true� �� then
�� t �� h� �� �put�s�adr� h��
sv�assign� �� t �� �s�true���� n �� �s�true��sv� �� b �� �s�true������true�
else �� t�n� �� b �� �err�false���� t �� t� �� �s�true� �� �� t �� �s�true� � �� t� �� �s�true���� t � t� �� �s�true� �� �� t �� �s�true� �� �� t� �� �s�true��
Abbildung ���� Semantikfunktionen f�ur Speicherzugri�e bei Arrays
Bemerkung zu Abbildung ���� Die Sequenz h��t� h�n���b� t�� h f�ur die Zuweisungeinzelner Felder wird durch eine Gleichung beschrieben� Dies verhindert einerseits dasAuftreten einer endlosen Rekursion� da sonst h�n���b wieder neu instanziert werdenk�onnte� und ist andererseits e�zienter bei der Termersetzung�
�
RECORD Type�RECORD Type�Field�SynCat�SemDom��trait
includes
Record�Record�Field��
Storable�RECORD Type�Record��
Storable�SynCat�SemDom�
introduces
� �RECORD Type�Field � SynCat
h�� RECORD Type
asserts
�s�Store�a�Loc�v�SV�b�SynCat�g�Field�t�t��RECORD Type�
b��Bool
� Zugriff auf ganzen Record�in Storable geregelt
� Zugriff auf ein Feld�
�� t�g �� �s�true� �� val�� �� t �� �s�true���g��� Zuweisung ganzer Record�in Storable geregelt
� Zuweisung einzelner Felder�
� h �� t� h�g �� b� t �� h�
� �� t�g �� b �� �s�true���M ��
�� t �� h� �� �put�s�adr� h��
sv�set� �� t �� �s�true��g�sv� �� b �� �s�true������true���� t �� t� �� �s�true� �� �� t �� �s�true� � �� t� �� �s�true���� t � t� �� �s�true� �� �� t �� �s�true� �� �� t� �� �s�true��
Abbildung ���� Semantikfunktionen f�ur Speicherzugri�e bei Records
BOOLEAN�trait
includes
Storable�BOOLEAN�Bool�
asserts
�b��b��BOOLEAN�s�Store�� TRUE �� �s�true� �� true�
�� FALSE �� �s�true� �� false�
�� � b� �� �s�true� �� � �� b� �� �s�true���� b� b� �� �s�true� �� �� b� �� �s�true� � �� b� �� �s�true���� b� j b� �� �s�true� �� �� b� �� �s�true� � �� b� �� �s�true���� b� �� b� �� �s�true� �� �� b� �� �s�true� � �� b� �� �s�true���� b� � b� �� �s�true� �� �� b� �� �s�true� �� �� b� �� �s�true��
Abbildung ����� Semantikfunktionen f�ur boolesche Ausdr�ucke
�
Ausdr�ucke mit ganzen Zahlen �Anhang B��� behandeln wir analog zu denbooleschen Ausdr�ucken� ausser dass bei kritischen Operationen zus�atzlicheine �Uberpr�ufung auf Bereichs�uberschreitungen �over�ow und under�ow�bzw� Divisionen durch Null vorgenommen wird�
����� Anweisungen Statements
Zuweisungen �Abb� ��� Die Semantik der Zuweisung wurde bereits bei derBeschreibung des Speichermodells behandelt�
Sequenz� Verzweigung� Schleife �Abb� ����� haben die �ubliche Semantik� Eswird z�B� spezi�ziert� dass die Ausf�uhrung der Sequenz s�� s auf einembestimmten Speicherzustand den gleichen E�ekt hat� wie die Ausf�uhrungvon s� auf dem alten und die anschliessende Ausf�uhrung von s auf demneuen Speicherzustand� LOOP�df�fs�� hat die Bedeutung einer FOR�Schleife �FOR d �� f� TO f DO s� END��
RETURN�Anweisung �Abb� ��� Mit Hilfe der RETURN�Anweisung wird einer Se�quenz von Anweisungen ein einzelner Wert �Resultat einer Funktionsproze�dur� zugeordnet� Ihre Bedeutung ist somit das Resultat der Evaluation desArgumentausdrucks auf dem aktuellen Speicherzustand� Indem wir festle�gen� dass RETURN�Statements ausschliesslich als letzte Anweisung innerhalbeines Prozedurrumpfs vorkommen� vereinfachen wir die Semantik von An�weisungssequenzen wesentlich�
�� Hierarchie der Semantik�Spezi�kation
Abbildung ��� vermittelt einen �Uberblick �uber die includes�Beziehungen zwi�schen den einzelnen traits der Semantik�Spezi�kation von OberonT�Ausser den bereits behandelten Spezi�kationen enth�alt Abbildung ��� die fol�genden traits �Anhang B�� ��
OberonT ist die Schnittstelle der Semantik�Spezi�kation der Implementations�sprache und wird in jede Spezi�kation eines neuen ADT importiert�
StandardTypes importiert alle Standard�Typen und wird zusammen mitARRAY OF Type und RECORD Type f�ur die Festlegung der Semantik von neude�nierten Typen gebraucht�
Orders spezi�ziert Ordnungsrelationen auf bin�ar repr�asentierten ganzen Zahlen�
BinaryNumbers spezi�ziert arithmetische Operationen auf bin�ar repr�asentiertenganzen Zahlen�
�
Statements�trait
includes
INTEGER�
BOOLEAN
introduces
skip�� Stmt
asserts
�b�BOOLEAN�d�f��f��INTEGER�s��s��Stmt�s�Store�a�Loc�v�SV
� �� s�� s� �� �s�true���M ��
� �� s� �� � �� s� �� �s�true���M��M�� �� IfThenElse�b�s��s�� �� �s�true���M ��
if� �� b �� �s�true�� then �� s� �� �s�true� else �� s� �� �s�true���� LOOP�d�f��f��s�� �� �s�true� ��
if� �� f� �� f� �� �s�true�� then
�� LOOP�d�succ�f���f��s�� �� � �� s� �� � �� d �� f� �� �s�true���else�s�true��
�� skip �� �s�true� �� �s�true��
Abbildung ����� Semantikfunktionen f�ur Anweisungen
Statements
OberonT
Array
ARRAY_OF_TypeBOOLEAN
Int
INTEGER
Record
RECORD_Type
StandardTypes
DecimalLiterals
Storable
Store
VariableId
Natural
AC
Orders
BinaryNumbers
Abbildung ���� Hierarchie der LSL�traits f�ur die Semantik�Spezi�kation
Natural spezi�ziert die Algebra nat�urlicher Zahlen�
AC spezi�ziert die Algebra assoziativ�kommutativer Operatoren�
DecimalLiterals spezi�ziert die Algebra dezimaler Literale �� �� s� �� ��
s���� �����
VariableId legt fest� dass jeweils zwei verschiedene Bezeichner f�ur eine Variableauch verschiedene Adressen im Speicher bezeichnen�
Literaturverzeichnis
�All��� L� Allison� A practical introduction to denotational semantics� Num�ber in Cambridge Computer Science Texts� Cambridge UniversityPress� �����
�Bau��� B� Baumgarten� Petri�Netze� BI � Wiss� � Verlag� �����
�BHK��� J� A� Bergstra� J� Heering� and P� Klint� editors� Algebraic Speci�ca�tion� Addison�Wesley� �����
�DS��� C� Denzler and D� Schweizer� PESCA� Programming Environmentfor Safety Critical Applications�http�##www�tik�ee�ethz�ch#$pesca#� �����
�EGL��� H� D� Ehrich� M� Gogolla� and U� W� Lipeck� Algebraische Spezi�ka�tion abstrakter Datentypen� Teubner� �����
�Gan� � H� Ganzinger� Denotational semantics for languages with modules�In D� Bjorner� editor� Formal description of programming concepts�North�Holland� ��� �
�GH��� J� V� Guttag and J� J� Horning� The algebraic speci�cation of ab�stract data types� Acta Informatica� ����%� �����
�GH� � J� V� Guttag and J� J� Horning� editors� Larch� Languages andTools for Formal Speci�cation� Texts and Monographs in ComputerScience� Springer�Verlag� ��� � With Stephen J� Garland� Kevin D�Jones� Andr&es Modet� and Jeannette M� Wing�
�GM��� J� A� Goguen and J� Meseguer� Order�Sorted Algebra I� CSL Tech�nical Report SRI�CSL������� SRI International� Computer ScienceLaboratory� July �����
�GPG��� J� A� Goguen and K� Parsaye�Ghomi� Algebraic denotational seman�tics using parameterized abstract modules� In J� Dias and I� Ramos�editors� Formalization of programming concepts� LNCS ���� Springer�Verlag� �����
�
�Gri��� D� Gries� The science of programming� Texts and Monographs inComputer Science� Springer�Verlag� �����
�GTW��� J� A� Goguen� J� W� Thatcher� and E� G� Wagner� An initial algebraapproach to the speci�cation� correctness and implementation of ab�stract data types� In R� Yeh� editor� Current Trends in ProgrammingMethodology IV� Data Structuring� Prentice�Hall� �����
�GWMJ�� J� A� Goguen� T� Winkler� J� Meseguer� and J��P� Jouannaud� Intro�ducing OBJ� CSL Technical Report SRI�CSL���� � SRI Internatio�nal� Computer Science Laboratory� March ����
�Hel�� A� Helbling� Spezi�zieren und Generieren von integrierten Umgebun�gen mit GIPSY� TIK�Report �� Institut TIK� ETH Z�urich�http�##www�tik�ee�ethz�ch� May ����
�Hoa�� C� A� R� Hoare� Proof of correctness of data representations� ActaInformatica� ����%��� ����
�Hoa��� C� A� R� Hoare� An overview of some formal methods for programdesign� IEEE Computer� pages �%��� September �����
�How�� D� Howe� On�line dictionary of computing�http�##wombat�doc�ic�ac�uk#� May ����
�Inm��� INMOS Limited� Transputer Reference Manual� �����
�Mar��� R� Marti� GIPSY� Ein Ansatz zum Entwurf integrierter Software�entwicklungssysteme� PhD thesis� Institut TIK� ETH Z�urich� �����Diss� ETH No� ���� �
�MoD��� UK Ministry of Defence� The Procurement of Safety Critical Softwa�re in Defence Equipment� Part�� Requirements� In Def Stan ����Part� � Issue � Directorate of Standards� �����
�Par��� H� Partsch� Speci�cation and Transformation of Programs� Textsand Monographs in Computer Science� Springer�Verlag� �����
�PBB��� P� Pepper� M� Broy� F� L� Bauer� H� Partsch� W� Dosch� and M� Wir�sing� Abstrakte Datentypen� Die algebraische Spezi�kation von Re�chenstrukturen� Informatik�Spektrum� ����%���� ����
�Rei��� W� Reisig� Petrinetze� Springer�Verlag� �����
�Rei�� M� Reiser� Programming in Oberon� ACM Press� ����
�Rus�� J� Rushby� Formal Methods and their Role in the Certi�cation ofCritical Systems� CSL Technical Report CSL����� SRI International�Computer Science Laboratory� March ����
�Sch� D� Schweizer� Ein neuer Ansatz zur Veri�kation von Programmen f�ursicherheitskritische Systeme� PhD thesis� Institut TIK� ETH Z�urich�in preparation�
�SK�� K� Slonneger and B� L� Kurtz� Formal Syntax and Semantics ofProgramming Languages� Addison�Wesley� ����
�Sta��� P� H� Starke� Analyse von Petri�Netz�Modellen� Leitf�aden und Mo�nographien der Informatik� Teubner� �����
�TM�� R� H� Thayer and A� D� McGettrick� editors� Software Engineering�IEEE Computer Society Press� ����
�Wir��� M� Wirsing� Algebraic Speci�cation� Semantics� Parameterizationand Re�nement� In E� J� Neuhold and M� Paul� editors� Formal De�scription of Programming Concepts� IFIP State�of�the�Art Reports�pages �% ��� Springer�Verlag� �����
�
Anhang A
Syntax�De�nitionen
A�� OberonT�Grammatik
A���� Scanner�Spezi�kationSCANNER OberonT�
CHARACTERS
eofC � ��X��
tabC � ���X��
eolC � ��DX��
blankC � ����X��
any � ��X���FFX� tabC eofC�
letter � �A��Z�a��z��
digit � �������
binaryDigit � ������
hexDigit � digit �A��F��
noQuote� � any ���� eolC�
noQuote� � any ��� eolC�
IGNORE
blankC
TOKENS
eof � eofC�
tab � tabC�
eol � eolC�
ident � letter �letter � digit��
integer � digit �digit� �digit �digit� CONTEXT ���� �digit �hexDigit� H � binaryDigit �binaryDigit� B�
char � �� noQuote� �� � � noQuote� � � digit �hexDigit� X�
string � ���noQuote� noQuote� �noQuote����� � ��noQuote� noQuote� �noQuote�����
COMMENT FROM �� TO �� NESTED
LITERALS
MODULE� IMPORT� BEGIN� END� ��� CONST� TYPE� VAR� PROCEDURE� �� �� ��
OF� ARRAY� RECORD� �� �� �� �� �� � TO� �� �� DO�
RETURN� IF� THEN� ELSE� �� ��� FOR� BY�
WITH� �� �� ��� �� ��� IN� �OR� DIV� MOD� �� �� �� �
END OberonT
�
A���� EBNF von OberonT
GRAMMAR OberonT�
SCANNER OberonTScanner�
SKIP
eol� tab�
NONTERMINAL Module
��� MODULE ident � �IMPORT Import Imports �� DeclSeq� END ident ��
NONTERMINAL Imports
��� �� Import Imports��
NONTERMINAL Import
��� ident�
NONTERMINAL DeclSeq�
��� DeclParts� ProcedureDecls�
NONTERMINAL DeclSeq�
��� DeclParts��
NONTERMINAL DeclParts�
��� �CONST ConstDeclarations� �TYPE TypeDeclarations��
NONTERMINAL DeclParts�
��� �VAR VarDeclarations��
NONTERMINAL ConstDeclarations
��� �ConstDeclaration � ConstDeclarations��
NONTERMINAL TypeDeclarations
��� �TypeDeclaration � TypeDeclarations��
NONTERMINAL VarDeclarations
��� �VarDeclaration � VarDeclarations��
NONTERMINAL ProcedureDecls
��� �PROCEDURE ProcedureDecl ProcedureDecls��
NONTERMINAL ConstDeclaration
��� IdentDef � ConstExpression�
NONTERMINAL VarDeclaration
��� IdentList � TypeQualIdent�
NONTERMINAL IdentList
��� IdentDef �� IdentList��
NONTERMINAL ConstExpression
��� Expression�
NONTERMINAL TypeDeclaration
��� IdentDef � Type�
NONTERMINAL Type
��� TypeQualIdent � ArrayType � RecordType�
NONTERMINAL TypeQualIdent
��� Object �� ident��
NONTERMINAL ArrayType
��� ARRAY �ConstExpressions� OF Type�
�
NONTERMINAL ConstExpressions
��� ConstExpression �� ConstExpressions��
NONTERMINAL RecordType
��� RECORD FieldLists END�
NONTERMINAL FieldLists
��� FieldList �� FieldLists��
NONTERMINAL FieldList
��� �Fields � Type��
NONTERMINAL Fields
��� IdentDef �� Fields��
NONTERMINAL ProcedureDecl
��� ProcedureHeading � ProcedureBody ident ��
NONTERMINAL ProcedureHeading
��� ��� IdentDef FormalParameters�
NONTERMINAL ProcedureBody
��� DeclSeq� �BEGIN StatSeq� END�
NONTERMINAL FormalParameters
��� � �FPSections� � � TypeQualIdent�
NONTERMINAL FPSections
��� FPSection �� FPSections��
NONTERMINAL FPSection
��� Idents � TypeQualIdent�
NONTERMINAL Idents
��� ident �� Idents��
NONTERMINAL StatSeq
��� Statement �� StatSeq��
NONTERMINAL Statement
��� � AssOrCall
� IfStatement
� ForStatement
� RETURN Expression
��
NONTERMINAL AssOrCall
��� Designator � �� Expression��
NONTERMINAL IfStatement
��� IF Expression THEN StatSeq
�ELSE StatSeq�
END�
NONTERMINAL ForStatement
��� FOR ident �� Expression TO Expression DO StatSeq END�
NONTERMINAL Expression
��� SimpleExpr �RelOp SimpleExpr��
NONTERMINAL RelOp
��� � � � � � � �� � � � ���
NONTERMINAL SimpleExpr
�
��� � � � AddOpExpr�
NONTERMINAL AddOpExpr
��� Term �AddOp AddOpExpr��
NONTERMINAL AddOp
��� � � OR�
NONTERMINAL Term
��� Factor �MulOp Term��
NONTERMINAL MulOp
��� � � DIV � MOD � ��
NONTERMINAL Factor
��� � Expression �
� � Factor
� Designator
� integer
� char
� string�
NONTERMINAL Designator
��� Object Extensions�
NONTERMINAL Extensions
��� ��� ident
� � Expression �
� � �Expression Expressions� ��
Extensions ��
NONTERMINAL Expressions
��� �� Expression Expressions��
NONTERMINAL IdentDef
��� ident �����
NONTERMINAL Object
��� ident�
END OberonT
��
A���� Signatur der konkreten SyntaxOberonTTerminals�trait
introduces
ident�� Ident
integer�� Integer
char�� Char
string�� String
eq�neq�lower�leq�greater�geq�� RelOp
plus�minus�or�� AddOp
times�div�mod�and�� MulOp
plus�minus�� Sign
asserts
sort Ident generated freely by
ident�� Ident
sort Integer generated freely by
integer�� Integer
sort Char generated freely by
char�� Char
sort String generated freely by
string�� String
sort RelOp generated freely by
eq�neq�lower�leq�greater�geq
sort AddOp generated freely by
plus�minus�or
sort MulOp generated freely by
times�div�mod�and
sort Sign generated freely by
plus�minus
OberonTSyntax�trait
includes
OberonTTerminals
introduces
module�Ident�Import�Imports�DeclSeq��Ident � Module
module�Ident�DeclSeq��Ident � Module
imports�Import�Imports � Imports
imports�� Imports
import�Ident � Import
declSeq��DeclParts��ProcedureDecls � DeclSeq�
declSeq��DeclParts� � DeclSeq�
declParts��� DeclParts�
declParts��ConstDeclarations � DeclParts�
declParts��TypeDeclarations � DeclParts�
declParts��ConstDeclarations�TypeDeclarations � DeclParts�
declParts��� DeclParts�
declParts��VarDeclarations � DeclParts�
constDeclarations�� ConstDeclarations
constDeclarations�ConstDeclaration�ConstDeclarations � ConstDeclarations
typeDeclarations�� TypeDeclarations
typeDeclarations�TypeDeclaration�TypeDeclarations � TypeDeclarations
varDeclarations�� VarDeclarations
varDeclarations�VarDeclaration�VarDeclarations � VarDeclarations
procedureDecls�� ProcedureDecls
procedureDecls�ProcedureDecl�ProcedureDecls � ProcedureDecls
constDeclaration�IdentDef�ConstExpression � ConstDeclaration
varDeclaration�IdentList�TypeQualIdent � VarDeclaration
identList�IdentDef � IdentList
identList�IdentDef�IdentList � IdentList
constExpression�Expression � ConstExpression
typeDeclaration�IdentDef�Type � TypeDeclaration
type�TypeQualIdent � Type
type�ArrayType � Type
type�RecordType � Type
��
typeQualIdent�Object � TypeQualIdent
typeQualIdent�Object�Ident � TypeQualIdent
arrayType�Type � ArrayType
arrayType�ConstExpressions�Type � ArrayType
constExpressions�ConstExpression � ConstExpressions
constExpressions�ConstExpression�ConstExpressions � ConstExpressions
recordType�FieldLists � RecordType
fieldLists�FieldList � FieldLists�
fieldLists�FieldList�FieldLists � FieldLists
fieldList�� FieldList�
fieldList�Fields�Type � FieldList
fields�IdentDef � Fields�
fields�IdentDef�Fields � Fields
procedureDecl�ProcedureHeading�ProcedureBody�Ident � ProcedureDecl
procedureHeading�IdentDef�FormalParameters � ProcedureHeading
procedureBody�DeclSeq� � ProcedureBody
procedureBody�DeclSeq��StatSeq � ProcedureBody
formalParameters�TypeQualIdent � FormalParameters
formalParameters�FPSections�TypeQualIdent � FormalParameters
fPSections�FPSection � FPSections
fPSections�FPSection�FPSections � FPSections
fPSection�Idents�TypeQualIdent � FPSection
idents�Ident � Idents
idents�Ident�Idents � Idents
statSeq�Statement � StatSeq
statSeq�Statement�StatSeq � StatSeq
statement�� Statement
statement�AssOrCall � Statement
statement�IfStatement � Statement
statement�ForStatement � Statement
statement�Expression � Statement
assOrCall�Designator � AssOrCall
assOrCall�Designator�Expression � AssOrCall
ifStatement�Expression�StatSeq�StatSeq � IfStatement
ifStatement�Expression�StatSeq � IfStatement
forStatement�Ident�Expression�Expression�StatSeq � ForStatement
expression�SimpleExpr � Expression
expression�SimpleExpr�RelOp�SimpleExpr � Expression
simpleExpr�AddOpExpr � SimpleExpr
simpleExpr�Sign�AddOpExpr � SimpleExpr
addOpExpr�Term � AddOpExpr
addOpExpr�Term�AddOp�AddOpExpr � AddOpExpr
term�Factor � Term
term�Factor�MulOp�Term � Term
factor�Expression � Factor
factor�Factor � Factor
factor�Designator � Factor
factor�Integer � Factor
factor�Char � Factor
factor�String � Factor
designator�Object�Extensions � Designator
extensions�� Extensions
extensions�Ident�Extensions � Extensions
extensions�Expression�Expressions�Extensions� Extensions
extensions�Extensions � Extensions
expressions�� Expressions
expressions�Expression�Expressions � Expressions
identDef�Ident � IdentDef
object�Ident � Object
asserts
sort Module generated freely by
module�Ident�Import�Imports�DeclSeq��Ident � Module�
module�Ident�DeclSeq��Ident � Module
sort Imports generated freely by
imports�Import�Imports � Imports�
�
imports�� Imports
sort Import generated freely by
import�Ident � Import
sort DeclSeq� generated freely by
declSeq��DeclParts��ProcedureDecls � DeclSeq�
sort DeclSeq� generated freely by
declSeq��DeclParts� � DeclSeq�
sort DeclParts� generated freely by
declParts��� DeclParts��
declParts��ConstDeclarations � DeclParts��
declParts��TypeDeclarations � DeclParts��
declParts��ConstDeclarations�TypeDeclarations � DeclParts�
sort DeclParts� generated freely by
declParts��� DeclParts��
declParts��VarDeclarations � DeclParts�
sort ConstDeclarations generated freely by
constDeclarations�� ConstDeclarations�
constDeclarations�ConstDeclaration�ConstDeclarations � ConstDeclarations
sort TypeDeclarations generated freely by
typeDeclarations�� TypeDeclarations�
typeDeclarations�TypeDeclaration�TypeDeclarations � TypeDeclarations
sort VarDeclarations generated freely by
varDeclarations�� VarDeclarations�
varDeclarations�VarDeclaration�VarDeclarations � VarDeclarations
sort ProcedureDecls generated freely by
procedureDecls�� ProcedureDecls�
procedureDecls�ProcedureDecl�ProcedureDecls � ProcedureDecls
sort ConstDeclaration generated freely by
constDeclaration�IdentDef�ConstExpression � ConstDeclaration
sort ConstExpression generated freely by
constExpression�Expression � ConstExpression
sort TypeDeclaration generated freely by
typeDeclaration�IdentDef�Type � TypeDeclaration
sort Type generated freely by
type�TypeQualIdent � Type�
type�ArrayType � Type�
type�RecordType � Type
sort TypeQualIdent generated freely by
typeQualIdent�Object � TypeQualIdent�
typeQualIdent�Object�Ident � TypeQualIdent
sort ArrayType generated freely by
arrayType�Type � ArrayType�
arrayType�ConstExpressions�Type � ArrayType
sort ConstExpressions generated freely by
constExpressions�ConstExpression � ConstExpressions�
constExpressions�ConstExpression�ConstExpressions � ConstExpressions
sort RecordType generated freely by
recordType�FieldLists � RecordType
sort FieldLists generated freely by
fieldLists�FieldList � FieldLists�
fieldLists�FieldList�FieldLists � FieldLists
sort FieldList generated freely by
fieldList�� FieldList�
fieldList�Fields�Type � FieldList
sort Fields generated freely by
fields�IdentDef � Fields�
fields�IdentDef�Fields � Fields
sort ProcedureDecl generated freely by
procedureDecl�ProcedureHeading�ProcedureBody�Ident � ProcedureDecl
sort ProcedureHeading generated freely by
procedureHeading�IdentDef�FormalParameters � ProcedureHeading
sort ProcedureBody generated freely by
procedureBody�DeclSeq� � ProcedureBody�
procedureBody�DeclSeq��StatSeq � ProcedureBody
sort FormalParameters generated freely by
�
formalParameters�TypeQualIdent � FormalParameters�
formalParameters�FPSections�TypeQualIdent � FormalParameters
sort FPSections generated freely by
fPSections�FPSection � FPSections�
fPSections�FPSection�FPSections � FPSections
sort FPSection generated freely by
fPSection�Idents�TypeQualIdent � FPSection
sort Idents generated freely by
idents�Ident � Idents�
idents�Ident�Idents � Idents
sort StatSeq generated freely by
statSeq�Statement � StatSeq�
statSeq�Statement�StatSeq � StatSeq
sort Statement generated freely by
statement�� Statement�
statement�AssOrCall � Statement�
statement�IfStatement � Statement�
statement�ForStatement � Statement�
statement�Expression � Statement
sort AssOrCall generated freely by
assOrCall�Designator � AssOrCall�
assOrCall�Designator�Expression � AssOrCall
sort IfStatement generated freely by
ifStatement�Expression�StatSeq�StatSeq � IfStatement�
ifStatement�Expression�StatSeq � IfStatement
sort ForStatement generated freely by
forStatement�Ident�Expression�Expression�StatSeq � ForStatement
sort Expression generated freely by
expression�SimpleExpr � Expression�
expression�SimpleExpr�RelOp�SimpleExpr � Expression
sort SimpleExpr generated freely by
simpleExpr�AddOpExpr � SimpleExpr�
simpleExpr�Sign�AddOpExpr � SimpleExpr
sort AddOpExpr generated freely by
addOpExpr�Term � AddOpExpr�
addOpExpr�Term�AddOp�AddOpExpr � AddOpExpr
sort Term generated freely by
term�Factor � Term�
term�Factor�MulOp�Term � Term
sort Factor generated freely by
factor�Expression � Factor�
factor�Factor � Factor�
factor�Designator � Factor�
factor�Integer � Factor�
factor�Char � Factor�
factor�String � Factor
sort Designator generated freely by
designator�Object�Extensions � Designator
sort Extensions generated freely by
extensions�� Extensions�
extensions�Ident�Extensions � Extensions�
extensions�Expression�Expressions�Extensions� Extensions�
extensions�Extensions � Extensions
sort Expressions generated freely by
expressions�� Expressions�
expressions�Expression�Expressions � Expressions
sort IdentDef generated freely by
identDef�Ident � IdentDef
sort Object generated freely by
object�Ident � Object
��
Anhang B
OberonT Semantik�Spezi�kationen
B�� Boolesche Algebra
B���� Semantischer BereichBoolean� trait
introduces
true� false� � Bool
� � Bool � Bool
� � � � � � Bool� Bool � Bool
asserts
Bool generated by true� false
� b� Bool
� true �� false�
� false �� true�
true � b �� b�
false � b �� false�
true � b �� true�
false � b �� b�
true � b �� b�
false � b �� true
implies
AC �� � Bool��
AC ��� Bool��
Distributive �� for � � for �� Bool for T��
Distributive �� for � � for �� Bool for T��
Involutive �� � Bool��
Transitive �� for �� Bool for T�
� b�� b�� b�� Bool
��b� � b�� �� �b� � �b����b� � b�� �� �b� � �b��b� � �b� � b�� �� b��
b� � �b� � b�� �� b��
b� � �b���b� � b�� � �b� � b�� � �b� � b���
b� � b� �� �b� � b�
�
B�� Algebra ganzer Zahlen
B���� Semantischer BereichInt�Int��trait
includes
DecimalLiterals�s for succ�Int for N��
Orders�Int�
Orders�B��trait
includes
BinaryNumbers�B�
introduces
� � �� � � � �� �B�B � Bool
inRange�range�B�B�B � Bool
asserts
�x�y�z�B�n�N�i�j�Digit�a�b�Boolx � x �� false�
x � y �� isNeg�x y��
x �� y �� ��y � x��
x � y �� y � x�
x �� y �� ��x � y��
inRange�x�y�z� �� x �� y � y �� z�
range�x�y�z� �� if isNeg�z x� then false else
range�nat����nat�y x��nat�z x���
implies
�x�y�z�x��z��B�n�Nrange�x�y�z� �� inRange�x�y�z��
�x� �� x � z �� z�� �� �inRange�x �y�z� �� inRange�x� �y�z����
converts
� �B�B � Bool�
�� �B�B � Bool�
� �B�B � Bool�
�� �B�B � Bool�
inRange�range�B�B�B � Bool
BinaryNumbers�B��trait
includes
AC� �B��
AC���B��
Natural�N�
introduces
����� Digit
��l�� B
� �B�Digit � B
s�B � B
� � � �div�mod�B�B � B
�B � B
isZero�isNeg�B � Bool
isNeg�B�B � Bool
inv�B � B
compl�B � B
abs�B � B
nat�B � N
int�N � B
asserts
sort Digit generated freely by ���
sort B generated by ��l� �
�x�y�B�n�N�i�Digits��� �� ����
s�l� �� ��
��
s�x��� �� x���
s�x��� �� s�x����
x � �� x�
l l �� l���
x�� l �� �x l����
x�� l �� x���
x�i y�� �� �x y� � i�
x�� y�� �� s�x y� � ��
x � � �� ��
x � l �� compl�x��
x � y�� �� �x�y����
x � y�� �� ��x�y���� x�
x �� compl�x��
x y �� x compl�y��
isZero�x� �� x � ��
isNeg��� �� false�
isNeg�l��
isNeg�x��� �� isNeg�x��
isNeg�x��� �� isNeg�x��
isNeg�x�y� �� �isNeg�x� � �isNeg�y�� � ��isNeg�x� � isNeg�y���
inv��� �� l�
inv�l� �� ��
inv�x��� �� inv�x����
inv�x��� �� inv�x����
compl�x� �� s�inv�x���
��B � l �� false�
��� �� ��
� � x�� �� false�
l � x�� �� false�
l�� �� l�
x�� � y�� �� false�
x�� � y�� �� false�
x�� � y�� �� x � y�
x�� � y�� �� x � y�
nat��� �� ��
nat�x��� �� � � nat�x��
nat�x��� �� �� � nat�x�� ��
int�nat�x�� �� x�
int��� �� ��
int�s�n�� �� s�int�n���
nat�int�n�� �� n�
abs�x� �� if isNeg�x� then x else x�
div�x�y� �� if isNeg�x�y� then int�div�nat�abs�x���nat�abs�y����
else int�div�nat�abs�x���nat�abs�y�����
mod�x�y� �� int�mod�nat�abs�x���nat�abs�y�����
implies
�x�y�z�B�n�N�i�j�Digit�a�b�Boolinv�inv�x�� � x�
compl�compl�x�� � x�
nat�x� � n �� x � int�n��
x y � � �� x � y�
x y�i � z�j �� x � z�j y�i�
x y�i � � �� x � y�i�
a � b �� ���a � �b���x y� �� �x� �y��
x z � y z �� x � y�
x z � y z �� x � y�
converts
isZero�isNeg�B � Bool�isNeg�B�B � Bool�inv�compl�abs�
s�B � B� �B � B�
�B�B � B� � �B�B � B� �B�B � B�
div�B�B � B�mod�B�B � B�
nat�int
exempting nat�l�
��
Natural�N��trait
includes
DecimalLiterals�s for succ��
AC� �N��
AC���N�
introduces
��� N
s�N � N
� � � �N�N � N
div�mod�N�N � N
� � �� � � � �� �N�N � Bool
range�N�N�N � Bool
asserts
N generated freely by ��s
�x�y�i�Nx � �� x�
x s�y� �� s�x y��
x � �� x�
s�x� s�y� �� x y�
x � � �� ��
x � s�y� �� x �x � y��
s�x� � s�y� �� x � y�
� � s�x� �� false�
s�x� � � �� false�
x � � �� false�
� � s�x��
s�x� � s�y� �� x � y�
x �� y �� ��y � x��
x � y �� y � x�
x �� y �� ��x � y��
range���i��� �� i � ��
range���i�s�x�� �� ��i � s�x� � �range���i�x���range�s�x��i��� �� ��i � s�x� � �range�x�i�����range�s�x��i�s�y�� �� ��i � s�x� � i � s�y� � �range�x�i�y���div���s�x�� �� ��
div�s�x��s�y�� �� if s�x� � s�y� then � else s�div�x y�s�y����
mod���s�x�� �� ��
mod�s�x��s�y�� �� if s�x� � s�y� then s�x� else mod�x y�s�y���
implies
converts
� � � �N�N � N�
� � �� � � � �� �N�N � Bool�
range�N�N�N � Bool�
div�mod
exempting �x�N � x�div�x����mod�x���
B���� Semantische Funktion
INTEGER�trait
includes
BOOLEAN�
Int�Int��
Storable�INTEGER�Int�
introduces
range�INTEGER�INTEGER�INTEGER � BOOLEAN
MAXINT�MININT�� Int
asserts
�j�j��j��INTEGER�s�StoreMAXINT �� ��������������������������������
MININT �� l�������������������������������
� �� �s�true� �� ��
� �� �s�true� �� ��
��
j� j� �� �s�true� �� if inRange�MININT� j� �� �s�true� j� �� �s�true��MAXINT� then
j� �� �s�true� j� �� �s�true� else j� j� �� �err�false�� j� j� �� �s�true� �� if inRange�MININT� j� �� �s�true� j� �� �s�true��MAXINT� then
j� �� �s�true� j� �� �s�true� else j� j� �� �err�false�� j� � j� �� �s�true� �� if inRange�MININT� j� �� �s�true� � j� �� �s�true��MAXINT� then
j� �� �s�true� � j� �� �s�true� else j� � j� �� �err�false�� j� � j� �� �s�true� �� j� �� �s�true� � j� �� �s�true�� j� �� j� �� �s�true� �� j� �� �s�true� �� j� �� �s�true�� j� � j� �� �s�true� �� j� �� �s�true� � j� �� �s�true�� j� �� j� �� �s�true� �� j� �� �s�true� �� j� �� �s�true�� j� �� j� �� �s�true� �� j� �� �s�true� � j� �� �s�true�� j� � j� �� �s�true� �� j� �� �s�true� � j� �� �s�true�� DIV�j��j�� �� �s�true� �� if� j� �� �s�true� � �� then
div� j� �� �s�true�� j� �� �s�true�� else DIV�j��j�� �� �err�false�� MOD�j��j�� �� �s�true� �� if� j� �� �s�true� � �� then
mod� j� �� �s�true�� j� �� �s�true�� else MOD�j��j�� �� �err�false�� succ�j�� �� �s�true� �� s� j� �� �s�true��� j� �� �s�true� �� if MININT � j� �� �s�true� then
� j� �� �s�true�� else j� �� �err�false�� range�j��j�j�� �� �s�true� �� range� j� �� �s�true�� j �� �s�true�� j� �� �s�true���
B���� DiverseOberonT�trait
includes
Statements
StandardTypes�trait
includes
BOOLEAN�
INTEGER
AC��T��traitintroduces �T�T � T
asserts �x�y�z�T�x y� z �� x �y z��
x y �� y x
implies
Associative�
Commutative�T for Range�
DecimalLiterals�N��trait
� A builtin trait schema given here
� for documentation only
introduces
�������������� �!�������� �����
�� N
succ�N � N
asserts equations
� �� succ����
� �� succ����
� �� succ����
� ��� as far as needed for any literals
� of sort N appearing in the including trait
VariableId�A��trait
introduces
var�L � Bool
uneq�A�L � Bool
��