<< zurück

MBSE Home

weiter >>

A Sprachdarstellung durch Syntaxklassendiagramme

Sprachen werden zur Darstellung und zur Kommunikation von Information eingesetzt. Es gibt viele verschiedene Sprachformen. Dazu gehören textuelle, diagrammatische, visuelle oder durch Töne übertragene Sprachen. Allen Sprachen aber ist der Aufbau auf Basis eines Vokabulars von Grundelementen gemeinsam. Die meist auch Zeichen genannten Grundelemente werden gemäß den in einer Grammatik zusammengefassten Regeln zu sinnvollen und komplexeren Aussagen gruppiert. Sowohl in der Linguistik als auch der Informatik wird deshalb eine Sprache normalerweise als die Menge der wohlgeformten Sätze verstanden, die zu dieser Sprache gehören [HU90]. Auf dieser Erkenntnis basiert eine elegante und gut ausgearbeitete Theorie zur Darstellung von textuellen Sprachen, die sich in der Chomsky-Hierarchie manifestiert und mit der erweiterten Backus-Naur-Form (EBNF) eine praktische Form der Nutzung gefunden hat. EBNF und verwandte Ansätze werden heute zur Darstellung von Programmiersprachen wie zum Beispiel Java [GJSB05] eingesetzt. Auch die XML [McL01] und die darin enthaltene Definitionssprache für XML-Dokumente basiert im Wesentlichen auf diesen Konzepten.

Diese textuelle Form der Grammatiken eignet sich jedoch nicht für die Darstellung von Sprachen wie der UML, die fast alle auf Diagrammen basieren. Aufgrund der nichtlinearen, zweidimensionalen Struktur von Diagrammen ist die Darstellung einer derartigen Sprache notwendigerweise komplexer. Ein gut ausgearbeiteter Ansatz steht mit der Erweiterung der Grammatiken auf Graphen, den Graphgrammatiken [Nag79, Roz99, EEKR99], zur Verfügung. Dieser Ansatz hat sich jedoch bei der Darstellung der UML nicht durchsetzen können. Teilweise ist dies dadurch begründet, dass die Eleganz und Einfachheit textueller Grammatiken bei Graphgrammatiken nicht beibehalten werden konnte. Hauptsächlich jedoch werden Graphgrammatiken deshalb nicht verwendet, weil die UML mit Klassendiagrammen eine Beschreibungssprache besitzt, die durchaus zur Beschreibung graphischer Sprachen angewandt werden kann.

Die Metamodellierung [RA01, CEK01, CEK⁺00] nutzt primär Klassendiagramme als zugrunde liegende Notation. Ein Metamodell definiert die abstrakte Syntax einer graphischen Notation. Seit der UML-Standardisierung ist es üblich, als Metamodell-Sprache selbst eine einfache Form von Klassendiagrammen einzusetzen. Dieser Ansatz hat den Vorteil, dass nur eine Sprache erlernt werden muss. Gleichzeitig setzt sich dieser Ansatz aber der Angreifbarkeit zirkulärer Definitionen aus. Viele Beispiele, wie der erfolgreiche Einsatz der deutschen Sprache zur Beschreibung der deutschen Grammatik oder der EBNF für die Definition der EBNF zeigen, dass zirkuläres Vorgehen für praktische Zwecke akzeptabel ist. Wir nutzen deshalb eine Kombination aus einer EBNF-Grammatik und Syntaxklassendiagrammen (SCD), mit der textuelle und diagrammatische Anteile der UML/P-Notation definiert werden.

Viele heutige Systeme wie SAP-Produkte oder Anlagen-Betriebssoftware müssen hochgradig konfigurabel und oft auch während des Betriebs durch zusätzliche Funktionen/Berechnungen ergänzbar sein. Austauschbare Komponenten, wie etwa Auto-Steuergeräte oder Plugins in erweiterbaren Architekturen, müssen ebenfalls nach Fertigstellung des Produkts konfiguriert werden können. Eine elegante Möglichkeit zur Konfiguration des Produkts ist die Interpretation von dynamisch ladbaren Modellen zur Laufzeit. In diesem Fall wird statt der Generierung von Code, der dann statisch fixiert ist, beim Start oder sogar während des Ablaufs des Produktivsystems das Modell geladen und entsprechend genutzt. Dazu ist aber unter anderem eine explizite Repräsentation des Modells notwendig. Mit den Techniken der Metamodellierung, die die abstrakte Syntax eines Modells darstellen kann, kann so auch eine explizite Konfiguration mit Modellen vorgenommen werden. Models@ run.time [BBF09, FR07] diskutiert damit mögliche Formen der Software Entwicklung.

In der einfachsten Form nutzt man dynamisch ladbare Modellen zur Konfiguration des Systems. Weitere Flexibilität, aber auch mehr Risiko erhält man, wenn das System selbst seine Modelle manipulieren kann, indem es etwa über die Metamodell-Struktur schreibend neue Modell-Elemente erzeugt oder umbaut. Eine solche manipulationsfähige Architektur ist gleichzeitig flexibel und riskant, wie die mittlerweile vielen Anwendungen von Reflection und gleichzeitig vielen Softwaretechnik-Guidelines gegen Reflection zeigen. Java bietet eine Reflection-API, bei der eine Inspektion und Manipulation der Objekte, sowie die Inspektion aber eine Manipulation der Klassenstruktur möglich ist. Das wäre analog dazu, das Metamodell fixiert aber inspizierbar zu halten, aber die Modelle auch verändern zu können.

Die explizite Repräsentation von Modellen zur Laufzeit des Systems erfordert die Integration von Teilen der Entwurfswerkzeuge in die Laufzeitsysteme und lässt so den Unterschied zwischen Entwurfswerkzeug und Produkt verschwimmen. Typischerweise ist das von der Programmiersprache angebotene Typsystem dabei im Weg und muss ausgehebelt werden oder eine Sprache eingesetzt werden, die kein überprüfbares Typsystem einsetzt. Smalltalk-Entwicklungsumgebungen [Gol84] zeigen, wie so etwas aussehen dürfte. Wesentliche Risiken dabei sind die Komplexität und Unüberschaubarkeit des Systems, die zunächst schlechtere Verständlichkeit der möglichen Verhalten, die schlechtere Testbarkeit, Wartbarkeit und Weiterentwickelbarkeit. Demgegenüber wird das System deutlich flexibler einsetzbar, besser konfigurierbar und ist vor allem bei sich dynamisch ändernden oder individuellen Anforderungen besser gewachsen. Einige Einsatzmöglichkeiten sind etwa:

• Interpretation von Verhaltensmodellen zur Funktionsbeschreibung,
• Datenstrukturmodellierung, zur Anpassung generischer Algorithmen für Speicherung, Anzeige, Aggregation und Reporting von Daten und Fakten,
• Diagnose-, Constraint- und Plausibilisierungs-Regeln,
• Definition von Masken für Bildschirme,
• Definition von Aggregationen und Reports aus Datenbeständen,
• Definition von automatisierten Abläufen oder Abläufen mit menschlicher Beteiligung (Workflows).

Bei der im UML-Standard [OMG10a] genutzten Form der Metamodellierung kommen vor allem Klassendiagramme zum Einsatz, die bei Bedarf durch OCL-Bedingungen ergänzt werden. Jedoch werden bei weitem nicht alle Konzepte der Klassendiagramme eingesetzt. Deshalb wird in diesem Abschnitt eine Teilmenge der in Klassendiagrammen angebotenen Konzepte identifiziert und vorgeschlagen, nur diese Teilmenge zur Modellierung der abstrakten Syntax einer graphischen Notation zu verwenden. Zur expliziten Unterscheidung zwischen Klassendiagrammen der UML und der zur Sprachdefinition verwendeten Klassendiagramme werden letztere durch einige syntaktische Modifikatoren kenntlich gemacht. Abbildung A.1 zeigt ein Syntaxklassendiagramm, das einen endlichen Automaten definiert.

Jede der sieben eingeführten Klassen entspricht einem Nichtterminal. Deshalb sind die Klassennamen, wie zum Beispiel ⟨Automat⟩ in Nichtterminalform dargestellt. Ein Syntaxklassendiagramm beinhaltet eine Hauptklasse, hier die Klasse ⟨Automat⟩, die als Axiom verstanden wird. Das heißt, die anderen sechs in Abbildung A.1 eingeführten Nichtterminale sind Teile des definierten Automaten. Dies wird durch das graphische Enthaltensein der zusätzlichen Nichtterminale in der Hauptklasse angezeigt. Alternativ ist es auch möglich, die Kompositionsbeziehungen zwischen dem Automaten und seinen Komponenten als Assoziation darzustellen. In Abbildung A.2 ist eine solche Alternativdarstellung für Automaten angegeben, die neben einer expliziten Darstellung dieser Kompositionsbeziehung weitere Alternativen zu der vorhergehenden Abbildung A.1 zeigt. Obwohl beide Syntaxklassendiagramme unterschiedliche Struktur haben, stellen sie nahezu dieselbe Information über Automaten dar. In Abbildung A.2 fehlt nur die Information, dass nur ein Startzustand pro Automat erlaubt ist.

Abbildung A.3 beschreibt die einzelnen Komponenten von Syntaxklassendiagrammen im Detail. In Syntaxklassendiagrammen werden weder Methoden noch Merkmale wie beispielsweise Sichtbarkeiten beschrieben. Sie spielen bei einer Sprachbeschreibung genauso wenig eine Rolle wie Interfaces. Jedoch ist es möglich den enthaltenen Klassen eine Kardinalität zuzuordnen. Als Standardwert wird die Kardinalität ⋆ angenommen. Die Kardinalität 1 markiert eine Singleton-Klasse.

Diese Kardinalität ist als Assoziations-Kardinalität der implizit gegebenen Assoziationen zwischen dem Axiom und dem markierten Nichtterminal zu verstehen. Abbildung A.2 zeigt diese Assoziationen und ihre Kardinalitäten explizit.

Die Begriffe „Nichtterminal“ und „Syntaxklasse“ betrachten wir als synonym und ersetzen damit den in der Metamodellierung verwendeten Begriff „Meta-Klasse“. Besonderer Erwähnung bedarf, dass in Syntaxklassendiagrammen Modifizierbarkeit keine Rolle spielt. Methoden und Kompositionsformen sind deshalb nicht von Bedeutung, weil Komposition sich vor allem auf den Lebenszyklus der daran beteiligten Objekte auswirkt. Auch Navigationsangaben spielen nur eine untergeordnete Rolle, zum Beispiel, um in einer reflexiven Assoziation eine Leserichtung zu beschreiben. Die genannten Modellierungskonzepte sind daher vor allem dazu gedacht, die Lesbarkeit eines Diagramms zu erhöhen. Die Lesbarkeit kann zusätzlich durch die Verwendung von Symbolen erhöht werden, die in ikonisierter Form das graphische Aussehen einer Syntaxklasse beschreiben. Abbildung A.4 stellt eine derartige Annotation der Abbildung A.1 dar.

Ein Klassendiagramm und damit auch ein SCD beschreibt eine Menge von möglichen Objektstrukturen. Bei einem SCD wie dem in Abbildung A.4 beschreibt jede dieser Objektstrukturen einen Automaten. Weil Objekte grundsätzlich eine Objektidentität besitzen, beinhaltet dieses SCD jedoch subtile Unterschiede zur mathematischen Definition von Automaten. So ist es laut SCD möglich, dass verschiedene Transitionen denselben Quell- und Zielzustand sowie dasselbe Zeichen tragen. Dem gegenüber wird in der mathematischen Modellierung typischerweise eine Transition durch diese drei Komponenten identifiziert. Eine geeignete Kontextbedingung, die zum Beispiel durch OCL formuliert werden kann, erlaubt es in SCDs die mathematische Modellierung nachzuvollziehen. Eine derartige Kontextbedingung ist zum Beispiel in Abbildung A.5 beschrieben.

Die Nutzung der OCL im Kontext von Syntaxklassendiagrammen wird durch eine spezielle Markierung rechts oben kenntlich gemacht. „SOCL“ steht für Syntax-OCL, also OCL angewandt auf eine Syntaxdefinition, wie sie mit einem Syntaxklassendiagramm durchgeführt werden kann. Dies erlaubt die Verwendung von Nichtterminalen wie ⟨Automat⟩ und ⟨transition⟩ als Klassen und zur Navigation. Mit obiger Bedingung wird ausgedrückt, dass für jeden Automaten a eine Invariante gilt, die besagt, dass wenn zwei Transitionen in Quellzustand, Zielzustand und Eingabezeichen übereinstimmen, so sie identisch sind. In der angegebenen Kontextbedingung wurde, wie in der OCL üblich, die Navigation entlang unbenannter Assoziationen anhand der Zielklasse vorgenommen. So können die einem Automaten a zugeordneten Transitionen auf Basis der implizit gegebenen Kompositionsbeziehung zwischen den Klassen ⟨Automat⟩ und ⟨Transition⟩ durch den Navigationsausdruck a.⟨transition⟩ dargestellt werden.

Weil bei einer Syntaxklasse die Interpretation als Menge von Modellelementen eine zentrale Rolle spielt, ist die Interpretation der Vererbungsbeziehung als Teilmengenrelation ebenfalls von Bedeutung. Im Beispiel A.1 wird die Menge der möglichen Zustände eines Automaten durch das Nichtterminal ⟨Zustand⟩ dargestellt. Diese Menge besitzt zwei Teilmengen, dargestellt durch ⟨StartZustand⟩ und ⟨EndZustand⟩, von denen jedoch weder festgelegt wurde, ob sie die Gesamtmenge der Zustände partitionieren, noch ob sie überlappungsfrei sind. Derartige Bedingungen wären durch zusätzliche Kontextbedingungen auszudrücken.

Auch aus pragmatischen Gründen ist es manchmal ratsam, auf die Darstellung eines Sachverhalts im SCD zu verzichten und ihn durch SOCL-Bedingungen zu beschreiben, weil das SCD sonst überladen werden würde. Ein Beispiel für den Verzicht auf Darstellung durch ein SCD sind etwa die Prioritäten von Infix-Operatoren, die bei Programmiersprachen-Grammatiken meist durch eine explizite Tabelle und nicht durch die kontextfreie Grammatik dargestellt werden. Es gibt also bei Benutzung von SCDs und SOCL-Kontextbedingungen einen großen Entwurfsspielraum zur Definition von Sprachen und zur Darstellung ihrer Syntax in lesbarer Form.

Durch die Kombination von SCDs mit der textuellen EBNF entstehen weitere Variationsmöglichkeiten. So können Syntaxklassen durch graphische Darstellung mit Assoziationen und Attributlisten oder durch textuelle Produktionen dargestellt werden. Dabei sind jedoch einige konzeptionelle Unterschiede beim Einsatz von SCDs und EBNF zu beachten.

Während in der EBNF zwischen dem definierenden und angewandten Auftreten eines Nichtterminals streng unterschieden wird, findet diese Unterscheidung im SCD nicht statt. In einer Produktion wird grundsätzlich das links stehende Nichtterminal definiert, während Nichtterminale im Ausdruck der rechten Seite nur verwendet werden. Eine Syntaxklasse wird durch die Darstellung in einem SCD gleichzeitig definiert und durch die Verbindung mit anderen Syntaxklassen im SCD verwendet. Formal könnten damit alle Erwähnungen von Syntaxklassen als definierend angesehen werden. Abhilfe kann hier unter Umständen die Verwendung von Kompositionsstrukturdiagrammen der UML 2.0 schaffen, indem davon ausgegangen wird, dass auftreten von Klassen in einem solchen Diagramm grundsätzlich nicht definierend für diese Klassen sind.

Im SCD in Abbildung C.2 wird von den drei Nichtterminalen ⟨Attribut⟩, ⟨Methode⟩ und ⟨Methodensignatur⟩ zwar die Existenz gefordert, jedoch keine detaillierte Definition angegeben. Dies kann aus dem Fehlen jeglicher Attribute geschlossen werden. In Abbildung C.3 sind diese Nichtterminale deshalb in EBNF-Form definiert.

Als pragmatische Regel zur Kombination von SCDs und EBNF-Produktionen kann deshalb festgelegt werden, dass die im SCD nicht weiter detaillierten Nichtterminale nur angewandt werden, während ihre Definition durch EBNF-Produktionen oder andere SCDs vorgenommen wird. Umgekehrt können in EBNF-Produktionen auf der rechten Seite verwendete Nichtterminale ihrerseits durch ein SCD definiert werden. Dadurch entsteht eine wechselseitige Integration von SCDs mit EBNF-Produktionen.

Wie in der objektorientierten Modellierung üblich und von der in dieser Arbeit propagierten Methodik vorgeschlagen, ist es möglich, mehrere Klassendiagramme zu nutzen, um unterschiedliche Teilaspekte von Systemen zu beschreiben. Diese Technik kann natürlich bei Syntaxklassendiagrammen ebenfalls verwendet werden. Ein Syntaxdiagramm stellt dann einen Ausschnitt der Gesamtsprache dar. Durch Verschmelzung aller Syntaxklassendiagramme entsteht dann eine umfassende Darstellung der beschriebenen Sprache.

Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012

<< zurück

MBSE Home

weiter >>