Domänenspezifische Editoren für die Entwicklung von Embedded Systems

1 Domänenspezifische Editoren für die Entwicklung von Embedded Systems Axel Terfloth, Svenja Wendler, Marc Habiger itemis GmbH & Co. KG, 44536 Lünen, axel.terfloth@itemis.de svenja.wendler@itemis.de marc.habiger@itemis.de Zusammenfassung: Im Bereich der Entwicklung von eingebetteten Systemen (Embedded Systems) existiert ein spezifisches Vokabular, welches im Wesentlichen durch die Ingenieurdomänen geprägt ist. Domänenspezifische Modellierungssprachen stellen ein adäquates Mittel dar, um dieses Vokabular im Rahmen der modellgetriebenen Entwicklung von eingebetteten Systemen direkt anzuwenden. Für solche Modellierungssprachen sind unterschiedliche Arten der Darstellung grafisch, textuell, baum- oder formularbasiert denkbar. In jedem Fall ist eine angemessene Unterstützung durch Modellierungswerkzeuge, insbesondere Editoren notwendig. Die Entwicklungsplattform Eclipse bietet mehrere Mechanismen, um eigene Editoren zu erstellen. Die zu berücksichtigenden Anforderungen und Möglichkeiten der Umsetzung werden im Folgenden betrachtet. Dieser Themenbereich wird im Rahmen des Forschungsprojektes 'mda4e' [MDA07] bearbeitet. Das Projekt wird durch die EU und den Europäischen Fonds für regionale Entwicklung (EFRE) gefördert. 1 DSL und DSE Im Bereich der Entwicklung von Embedded Systems fallen Begriffe wie 'Block', 'Sensor', 'Signal' oder 'Kennfeld'. Diese sind mögliche Elemente domänenspezifischer Sprachen (DSL) zur Beschreibung bzw. Modellierung von eingebetteten Systemen. Domänenspezifische Sprachen kennzeichnen sich durch ein schmales Vokabular im Gegensatz zu generell anwendbaren

2 Modellierungssprachen (general-purpose language, GPL), wie UML [OMG07b][BOE04]. Sie zeichnen sich durch eine leichtere Verständlichkeit für Domänenexperten aus. In der Domäne der Embedded Systems existierende modellbasierte Ansätze nutzen Modellierungssprachen, die meist domänenspezifisch geprägt sind. Die Nutzung domänenspezifischer Modellierungssprachen erfordert die Definition von Syntax und Semantik der Sprache. Dies geschieht durch die Festlegung von Metamodell und Notation für die Modelle. Ein Ansatz besteht darin Standardmodellierungssprachen, wie UML oder die auf der UML basierende SysML [OMG07] [TWE06] zu verwenden. Diese erlauben es DSLs mit Hilfe von Profilen zu definieren. Profile sind eine Standard konforme Erweiterung des UML- bzw. SysML-Metamodells. Alternativ können zur Umsetzung einer DSL Metamodell und Notation speziell zugeschnitten werden. Diese Herangehensweise bietet sich an, wenn UML als Basis nicht verwendet werden kann oder soll. Beide Ansätze besitzen ihre spezifischen Vor- und Nachteile. Für die Nutzung einer speziellen Modellierungssprache sprechen vor allem folgende Punkte: Nutzung bestehender Modellierungssprachen abseits der UML Kompakte Modelle und Metamodelle Nutzung von Modellen, die nur unzureichend oder gar nicht durch die UML unterstützt werden. Optimierungsmöglichkeiten durch Spezialisierung Dem gegenüber stehen die Vorteile, die Standardmodellierungssprachen und insbesondere die UML als 'Lingua Franca' des Software-Engineerings, besitzen [BER02]. Gerade im Hinblick auf die Werkzeugunterstützung gibt es für UML und SysML eine Reihe Modellierungstools. Bei der Nutzung von DSLs sind in der Regel keine Modelleditoren verfügbar. Diese müssen individuell entwickelt werden. Speziell an eine DSL angepasste Editoren nennen wir domänenspezifische Editoren (DSE). 2 Notationsformen Editoren sind für unterschiedliche Notationen optimiert. Die für

3 Modellierung relevanten Notationen lassen sich in verschiedene Kategorien unterteilen: 2.1 grafisch Die grafische Notation basiert auf Graphen, nutzt also Knoten, Kanten und Beschriftungen als Notationselemente. Sie zeichnet sich durch ihre visuelle Ausdruckskraft aus. Mittels grafischer Notationen ist es möglich, das Modell oder Teile des Modells anschaulich und einfach darzustellen. 2.2 textuell Die Syntax textueller Modelle kann in unterschiedlicher Form definiert werden. Hier sind vor allem XML-basierte Notationen zu nennen und solche die durch eine Grammatik z.b. in Form der erweiterten Backus- Naur-Form (EBNF) [WIK07] beschrieben werden können. 2.3 baumbasiert/hierarchisch Diese Notation ist eine Form von grafischer Notation, bei der die Elemente hierarchisch angeordnet sind. Diese Darstellungsform wird oft als Outline- View verwendet. Sie deckt eine spezielle Sicht auf ein Modell ab, welche einen schnellen Zugriff auf Modellelemente erlaubt. 2.4 formularbasierte Darstellung Die Darstellung und Bearbeitung von Modellinformationen in Formularen ist als Ergänzung der anderen genannten Notationsformen üblich und wird vor allem auf Detailinformationen angewendet. Daneben sind weitere Formen denkbar, auf die in diesem Beitrag nicht weiter eingegangen wird. 3 Anforderungen an domänenspezifische Editoren Modelleditoren stellen den primären Zugang des Modellierers bzw. Entwicklers zu den Modellen her. Damit sind die Eigenschaften von Editoren entscheidend für einen effizienten Umgang mit Modellen. Es gibt eine Reihe von funktionalen und nicht funktionalen Anforderungen, die domänenspezifische Editoren in diesem Hinblick erfüllen sollten. Neben diesen allgemeinen Anforderungen ist es mit DSEs auch möglich Anforderungen umzusetzen, die einen sehr effizienten Umgang mit

4 Modellen ermöglichen. 3.1 Unterstützung der Notation Domänenspezifische Editoren sind per Definition auf die Unterstützung einer speziellen DSL ausgerichtet. Durch die Notation wird festgelegt, ob der Editor grafisch, textuell oder formularbasiert arbeitet. Es müssen genau die Notationselemente unterstützt werden, die durch die DSL festgelegt wurden. 3.2 Spezielle Anforderungen an textuelle DSEs Für textuelle Modelle kann grundsätzlich jeder Texteditor verwendet werden. Für eine effizientes Arbeiten ist jedoch eine DSL-spezifische Unterstützung notwendig. Insbesondere Syntaxhervorhebungen und Code- Completion sollten Editoren unterstützen. 3.3 Validierung Ein Editor sollte den Modellierer dabei unterstützen korrekte Modelle zu erstellen. Dies bezieht sich sowohl auf die syntaktische als auch auf die semantische Korrektheit der Modelle. Wichtig ist hier ein möglichst frühes und direktes Feedback. Ein Editor kann dazu präventiv oder reaktiv agieren. Die präventiven Maßnahmen verhindern, dass bestimmte Fehler durch den Modellierer gemacht werden können. Ein Beispiel ist das Verbinden zweier Blockeingänge in einem Blockschaltdiagramm, in dem nur Blockeingänge mit Blockausgängen verbunden werden dürfen. Bei einem reaktiven Validierung kann der Modellierer fehlerhafte Modelle erstellen. Der Editor liefert dem Modellierer Informationen bezüglich der Fehler. Je nachdem ob dies automatisch oder durch eine explizit aufzurufende Validierungsfunktion erfolgt, spricht man auch von Live- und Batch-Validierung. Die Hinweise auf die Probleme sollten sowohl in einer Übersicht als auch nahe an den betroffenen Modellelementen dargestellt werden. Ein großer Teil der notwendigen Prüfungen ergibt sich aus dem jeweiligen Metamodell. Ein Beispiel sind hier die Kardinalitäten der Beziehungen zwischen Modellelementen. Weitere Prüfungsregeln können durch Constraints definiert werden. Constraints können dazu beispielsweise in OCL [OMG06] oder Check (openarchitectureware [OAW07]) ausgedrückt oder in Java implementiert werden.

5 3.4 Simulation Die Simulation von Teilsystemen ist ein wesentlicher Teil des Prozesses zur Entwicklung von eingebetteten Systemen, da während der Entwicklung der Software das eigentliche Zielsystem für Tests oftmals noch gar nicht zur Verfügung steht oder dessen Einbeziehung sehr aufwendig ist. Die Simulation ist prinzipiell auf alle Modelle anwendbar, die Verhalten beschreiben. Existieren für solche Modelle Simulations-Engines, dann können diese mit dem Editor gekoppelt werden. Als wesentlicher Punkt ist hier zu beachten, dass die Notation um zusätzliche dynamische Elemente erweitert werden muss, welche zur Darstellung der Simulation dienen. Abbildung 3.1: Notationselemente zur Visualisierung einer Simulation Bei der Simulation eines Zustandsautomaten können, wie in der Grafik dargestellt, aktive Zustände (Zustand 'B') und durchgeführte Transitionen ('B nach C') durch besondere Attributierung der vorhandenen Notationselemente hervorgehoben werden oder durch zusätzliche Elemente angezeigt werden. In Abbildung 3.1 ist das die Transition von B zu C. 3.5 Ergonomie Im Hinblick auf die Ergonomie und Benutzerfreundlichkeit sind domänenspezifische Editoren beliebig anpassbar. Je mehr Ergonomie gefordert wird, desto aufwendiger gestaltet sich auch die Entwicklung des Editors, wie dies allgemein bei Software der Fall ist. Der Vorteil bei selbst erstellten Editoren ist die Flexibilität in der Entwicklung, die bei Standardeditoren nicht oder kaum vorhanden ist. Einige UML-Tool- Hersteller bieten zu ihrem Werkzeug APIs an, welche für die Anpassung an die eigenen Bedürfnisse genutzt werden können [MDR07].

6 3.6 Kombination verschiedener Notationsformen Jede vorgestellte Notationsform besitzt spezifische Vor- und Nachteile. Aus diesem Grund bietet sich deren kombinierte Verwendung an, um den für den jeweiligen Zweck optimalen Zugriff auf das Modell anbieten zu können. Eine Kombination von hierarchischer Notation als Outline-View und grafischen oder textuellen Editoren gehört bereits zum Standard. Dabei ergänzen Formulare meist die grafische Repräsentation. Jedoch ist eine kombinierte Verwendung von grafischen und textuellen Darstellungsformen unüblich. Da sich grafische und textuelle Notationen sehr stark ergänzen, brächte eine Kombination beider einen deutlichen Mehrwert. Während die grafische Darstellung einen guten Überblick vermittelt, können Detailinformationen schnell in der textuellen Ansicht verändert werden [HAN05]. 4 Metamodellbildung DSLs erfordern die Definition von Metamodell und Notation(en). Metamodelle sind Instanzen von Meta-Metamodellen. Der Standard für Meta-Metamodelle ist MOF (Meta Object Facility) und wurde von der OMG standardisiert [OMG06c]. Es gibt eine abgespeckte Form von MOF - EMOF (Essential MOF). Dieses wurde in leicht abgewandelter Form für die Eclipse Plattform als ECORE umgesetzt. Mittels ECORE können eigene Metamodelle und domänenspezifische Sprachen definiert werden. Die hier vorgestellten Technologien sind allesamt Eclipse und damit auch ECORE-kompatibel. ECORE bildet damit auch den Kontext in dem in diesem Beitrag Metamodelle diskutiert werden 5 Implementierung domänenspezifischer Editoren Für die Open Source Plattform Eclipse gibt es verschiedene Werkzeuge und Frameworks mit deren Hilfe unterschiedliche Editoren ausgehend von einem Metamodell generiert und weiterentwickelt werden können [EMO07]. 5.1 Grafische Editoren Grafische Editoren für die Eclipse Plattform können mit unterschiedlichen Frameworks erstellt werden. Einige Beispiele sind:

7 GEF (Graphical Editing Framework) GMF (Graphical Modelling Framework) TOPCASED Obwohl alle Frameworks zur Erstellung von grafischen Editoren aufgebaut wurden, unterscheiden sie sich in ihrer Funktionalität. Jedoch erfüllen die grafischen Editoren die Forderung nach Trennung von reiner Modellinformation und grafischer Repräsentation des Modells, wie es in Abbildung 5.1 dargestellt ist. Das ermöglicht die Bearbeitung des Modells unabhängig vom Editor. Die OMG standardisierte ein derartiges Vorgehen für die UML im Diagramm Interchange Format [OMG06b]. Abbildung 5.1: Struktureller Aufbau eines grafischen Editors mit getrennten Modell- und Diagramminformationen Graphical Editing Framework (GEF) GEF bildet die Basis für GMF und TOPCASED. Das Framework ist eher eine Bibliothek und stellt Funktionen und grundlegende Konzepte für die Editoren bereit. Der Editor wird bei reiner Nutzung von GEF manuell implementiert. Vorteilhaft bei dieser Vorgehensweise ist die freie Gestaltungsmöglichkeit des Editors sowie die Unabhängigkeit von eventuell noch nicht ausgereiften Eclipse-Plugins, da GEF für sich verwendbar ist. Dem gegenüber steht ein erhöhter Zeitaufwand durch die manuelle Entwicklung. Graphical Modelling Framework GMF setzt auf GEF und EMF auf. Mit GMF ist es möglich einen grafischen Editor, der auf einem ECORE Modell basiert zu modellieren.

8 Der Editor wird generiert. Es gibt eine dokumentierte Schnittstelle, um den Editor mit erweiterten Möglichkeiten der Modellmanipulation auszustatten. Abbildung 5.2 zeigt einen exemplarischen, mit GMF erzeugten, Editor. Das zu Grunde liegende Metamodell beschreibt ein System, das aus unterschiedlichen Komponenten zusammengesetzt werden kann. Jede Komponente kann eine Schnittstelle anbieten bzw. nutzen, sowie Attribute oder andere Komponenten enthalten. Abbildung 5.2.: Mit GMF erstellter grafischer Editor Hervorzuheben sind auch die automatischen Validierungsmöglichkeiten des generierten Editors. Dem Metamodell können Rahmenbedingungen (so genannte Constraints) für Elemente mitgegeben werden. Diese werden direkt vom EMF-Validierungmechanismus, den GMF verwendet, zur Prüfung aufgegriffen. Dabei wird sowohl Batch-, als auch Live-Validierung unterstützt. Auch können bei der Editorerstellung bestimmte Verbindungen zwischen Elementen von vorn herein unterbunden werden. Auf diese Weise ist es gar nicht erst möglich derartige Modellierungsfehler zu begehen. Ein Beispiel hierfür wäre das Verhindern einer zirkulären Kompositionsbeziehung. TOPCASED TOPCASED ist ein Werkzeugsammlung für die Entwicklung sicherheitskritischer Echtzeitsysteme und basiert auf der Eclipse Plattform. Derzeit befindet sich TOPCASED noch in der Entwicklung, wobei die fortgeschrittenen Werkzeuge bereits verwendet werden, wie aus der

9 TOPCASED-Newsgroup hervorgeht [TPC07b]. Für eigene ECORE-basierende Metamodelle bietet TOPCASED einen Mechanismus zur Generierung grafischer Editoren an. Der Ansatz ist mit dem von GMF sehr vergleichbar. Ein Vergleich der beiden Werkzeuge GMF und TOPCASED ist Teil der Untersuchungen im Forschungsprojekt mda4e [MDA07]. 5.2 Textuelle Editoren Textuelle Editoren sind als Code-Editoren für Programmiersprachen bekannt, welche letztlich auch als Modelle angesehen werden können. Es ist möglich Grammatiken für domänenspezifische Sprachen zu definieren. Ausgehend von solchen Grammatiken können Texteditoren Syntax Highlighting, Code-Completion sowie online Syntaxprüfung unterstützen. Im Gegensatz zu grafischen Editoren bieten textuelle Editoren derzeit keine Trennung zwischen dem reinen Modell und der textuellen Repräsentation, wie dies in Abbildung 5.1 dargestellt ist. Abbildung 5.3: Struktureller Aufbau eines Texteditors Xtext Xtext ist Bestandteil von openarchitectureware (oaw) [OAW07] und ist ein Framework zur Erstellung von textbasierten domänenspezifischen Sprachen (DSL). Xtext wendet einen Grammatik-orientierten Ansatz an. Dort wird ausgehend von einer Grammatikdefinition Metamodell, Parser und Editor generiert. Die Grammatiksprache ist an die erweiterte Backus- Naur-Form angelehnt. Ein mittels Xtext erstellter Editor bietet Komfortfunktionen, wie Syntax

10 Highlighting und Code Completion. Darüber hinaus besitzt der generierte Editor neben der Textausgabe auch eine Baumansicht (Outline-View) auf das Modell. Xtext erlaubt die Verwendung anderer oaw-komponenten die nicht invasive Metamodellerweiterungen (oaw-xtend)und die Definition von Constraints erlauben (oaw-check). TCS TCS (= textual concrete syntax) verfolgt im Gegensatz zu Xtext einen Metamodellorientierten Ansatz. Hier wird ausgehend von einem existierenden Metamodell und einem TCS-Modell, in dem die textuelle Syntax für die Metamodellelemente definiert werden, eine Grammatik und Werkzeuge für Model-To-Text- und Text-To-Model-Transformationen zu generiert. Zusätzlich gibt es einen generischen Editor, der jeweils die konkrete definierte Syntax unterstützt [JBK06]. 5.3 Baumbasierte Editoren Baumbasierte Editoren stellen das Modell in hierarchischer Struktur dar. Oftmals werden grafische und textbasierte Editoren um eine so genannte Outline-View als Baumansicht ergänzt [TPC07]. Diese Editorgattung bietet sich als zusätzliche Ansicht bei grafischen und textuellen Editoren an. Abbildung 5.4.: Editor für eine Ecore-Datei als Beispiel für baumbasierte Editoren

11 Die Editoren des Eclipse Modeling Framework (EMF) sind Beispiele für baumbasierte Editoren, wie Abbildung 5.4 zeigt. Die Eigenschaften der Elemente können meistens in Eigenschaftsdialogen editiert werden. Eine erweiterte Form dieser Dialoge Panels sind formularbasierte Editoren. 5.4 Formularbasierte Editoren Rein formularbasierte Editoren treten nur bei sehr einfachen Modellen auf. In der Regel findet man sie als ergänzende Darstellungsform bei grafischen Editoren, beispielsweise als Eigenschaftsdialoge. Dort dienen sie im Wesentlichen dem Bearbeiten von Detailinformationen. 5.5 Wizards Abbildung 5.5.: Ein Wizard erleichtert die Modellerstellung bei TOPCASED Wizards sind meist formularbasierte Editoren, die eine Folge von Bearbeitungsschritten fest vorgeben. Oft werden Wizards nur einmalig verwendet und führen den Anwender durch initiale Arbeitsschritte. Der Benutzer wird anhand mehrerer Dialoge geführt. Durch die strikte Benutzerführung können Wizards dabei helfen Modellierungsfehler zu vermeiden. Ein sehr anschauliches Beispiel für einen Wizard bietet das TOPCASED Framework bei der Erstellung eines grafischen Editors (Abbildung 5.5). Hier wird ein Wizard verwendet, um ein Quell-Ziel-Paar zu definieren. Dabei ist das Quellobjekt das Modellelement, von dem aus die Verbindung zum Zielobjekt gezogen wird. Bei einer manuellen Zuordnung dieser Quell-Ziel-Paare gibt es auf Grund der vielen Möglichkeiten viele Fehlerquellen. Der Wizard wählt bereits die plausibelsten Möglichkeiten aus und wählt diese standardmäßig aus. So können Fehler vermieden werden und der Benutzer kann schneller arbeiten. Die Abbildung zeigt

12 beispielsweise, dass TargetToSourceRef nicht weiter spezifiziert werden muss. Bei Fehlmodellierung zeigt dieser Wizard sofort eine Fehlermeldung. 6 Simulation Für die Anbindung einer Simulations-Engine an einen Editor gibt es im Umfeld von Eclipse keine Standardschnittstellen und auch keine entsprechende Werkzeugunterstützung. Die für die Entwicklung von Editoren vorgestellten Technologien erlauben jedoch Anpassungen des Editors durch manuell implementierte Erweiterungen. Somit ist grundsätzlich eine Anbindung möglich. Ein erprobtes Beispiel hierzu ist eine Werkzeugkette mit einem DSE für Zustandsautomaten und dem Simulationsprogramm BORIS aus WinFACT [WIF07]. 7 Kombination grafischer und textueller Notationen Während die Stärke grafische Notationen vor allem darin besteht Beziehungen zwischen Modellelementen anschaulich darzustellen, sind textuelle Notationen besonders gut zur Beschreibung von Struktur und Detailinformationen einzelner Modellelemente geeignet. Weitere Vorteile textueller Notation sind bei entsprechender Werkzeugunterstützung eine sehr effiziente Editierbarkeit und die Möglichkeit einer einfachen Differenzbildung zwischen Modellen. Abbildung 7.1.: Textuelle Repräsentation (rechts) eines Blockdiagramms (links) In Abbildung 7.1 sind grafische und textuelle Notation eines Blockschaltsystems gegenübergestellt. Die grafische Notation bietet einen

13 guten Überblick der vorhandenen Blöcke und der Verbindungen zwischen diesen. Die Parameter sind hier nicht sichtbar und müssen einzeln in Dialoge eingetragen werden. In der textuellen Repräsentation sind sämtliche Parameter leicht ersichtlich und schnell zu pflegen. Die Anforderung, grafische und textuelle Notationen kombiniert zur Modellierung zu verwenden, impliziert eine ständige Konsistenz der grafischen und textuellen Sicht. Dies ist am einfachsten umzusetzen, wenn auf der Ebene der Modelle keine redundanten Informationen vorliegen. Dieses Szenario ist in Abbildung 7.2 dargestellt. Hier wird das von den grafischen Editoren bekannte Prinzip der Trennung von semantischen Modellelementen von notationsrelevanten Modellinformationen auf die textuelle Notation übertragen. In diesem Fall findet keine Speicherung des Modells in einer der Grammatik konformen Textform statt. Eine Anforderungen, die sich hieraus an die Editoren ergibt, ist die Konsistenz des jeweiligen Notationsmodells mit dem Domänenmodell sicherzustellen. Zwei der hier zu berücksichtigenden Fälle sind das Hinzufügen und Entfernen von Modellelementen. Da die Änderung jeweils in einer der Sichten stattfindet, können Änderungen Auto-Layout- Strategien in den Sichten erfordern. Abbildung 7.2: Kombination grafischer und textueller Notationen ohne Modellredundanzen Dieser Ansatz bietet sich vor allem dann an, wenn ausgehend von einem bestehenden Metamodell grafische und textuelle Notation definiert werden sollen. Leider gibt es für die Eclipse-Plattform keine Lösung, die eine Erstellung von domänenspezifischen Editoren unter Anwendung dieses Ansatzes unterstützt. Dies trifft vor allem auf den Bereich der textuellen

14 Notationen zu. Alternativ bietet es sich an die vorgestellten Ansätze zur Implementierung grafischer und textueller DSE's anzuwenden. In diesem Fall sind redundante Inhalte in den Modellen nicht zu vermeiden. Abbildung 7.3: Redundante Modellinformationen in Domänen- und Textmodell Dieser in Abbildung 7.3 dargestellte Ansatz erfordert zusätzlich zu den oben genannten Anforderungen eine Synchronisierung der Informationen zwischen Domänen- und Textmodell. Hierzu wird zum einen eine Text zu Modell Transformation (T2M) benötigt, welche die textuelle Repräsentation in das Domänenmodell überführt, zum anderen eine Modell zu Text Transformation (M2T) für die entgegengesetzte Richtung benötigt. In diesem Szenario sind sowohl Xtext als auch TCS anwendbar. Xtext bietet durch seinen Grammatik-orientierten Ansatz keine Unterstützung im Hinblick auf die genannten Transformationen. TCS hingegen adressiert durch seinen Metamodell-orientierten Ansatz genau dieses Thema. Der Spielraum für die verwendbaren Grammatiken ist jedoch wesentlich kleiner, da deren Struktur stark an der Struktur des Metamodells angelehnt sein müssen. Zusätzlich zu den sich aus den dargestellten Modellstrukturen ergebenen Aufgabenstellungen, müssen die Editoren zusätzliche Anforderungen erfüllen, die sich aus der kombinierten Verwendung grafischer und textueller Notationen ergeben:

15 Bei der Implementierung der Editoren muss berücksichtigt werden,dass die Synchronisierung im Rahmen der Benutzerinteraktion stattfinden muss, und für den Modellierer möglichst transparent sein sollte. Zusätzlich zur Navigation innerhalb einer Sicht (Text oder Grafik) muss auch die Navigation zwischen grafischer und textueller Sicht unterstützt werden Die Validierung muss konsistent behandelt werden. Insbesondere sollten die Prüfung von Constraints nicht spezifisch für die textuelle oder grafische Sichte erfolgen, sofern sie nicht auf die jeweilige konkrete Syntax beziehen. 8 Fazit Bei der Entwicklung von eingebetteten Systemen können domänenspezifische Editoren (DSE) Standardmodellierungswerkzeuge ergänzen oder ersetzen und den Systementwickler bei den Arbeiten mit Modellen effizient unterstützen. Wesentlich ist dabei, dass die den Editoren zu Grunde liegenden domänenspezifischen Sprachen gezielt Konzepte aus der Ingenieurwelt aufgreifen können, denen Standardwerkzeuge nicht ausreichend Rechnung tragen können. Die Editoren ermöglichen eine Modellierung, die auf den vorgegebenen Sprachraum der DSL beschränkt und somit weniger fehleranfällig ist. Es ist festzustellen, dass für die Eclipse-Plattform viele Werkzeuge und Frameworks existieren, welche die Implementierung von domänenspezifischen Editoren für eingebettete Systeme unterstützen. Jedoch sind auch bei den generativen Ansätzen in den meisten Fällen manuelle Erweiterungen der Implementierung notwendig. Besonders in den Bereichen 'Simulation' und 'Integration grafischer und textueller Notationen' ist die vorhandene Unterstützung unzureichend. Im Rahmen des Forschungsprojektes werden diese Bereiche betrachtet und Lösungsansätze erarbeitet.

16 Literatur [BER02] Frederic Bernard, Artikel: Wir verstehen uns mit UML, Content Manager, http://www.contentmanager.de/magazin/artikel_266_wir_verstehen_ uns_mit_uml.html [BOE04] Bernd Oestereich, Die UML 2.0 Kurzreferenz für die Praxis, Oldenbourg Verlag, 2004 [EMO07] Eclipse Modeling Framework, http://www.eclipse.org/modeling/, 2007 [HAN05] Graphical Modeling of Complex Reactive Systems, http://cs.unisalzburg.at/announcements/ Slides_vonHanxleden_060605.pdf [JBK06] Frederic Jounault, Jean Bezivin, Ivan Kurtev, TCL: a DSL for the Specification of Textual Concrete Syntaxes in Model Engineering, CPCE, 2006 [MDA07] Homepage Forschungsprojekt MDA für Embedded Systems, http://opensource.itemis.de/mda4e, 2007 [MDR07] MagicDraw OpenAPI, http://www.magicdraw.com/files/manuals/12.1/magicdraw%20ope napi%20userguide.pdf, 2007 [OAW07] OpenArchitectureWare Webseite, http://www.openarchitectureware.org, 2007 [OMG06] Object Constraint Language Specification, Version 2.0,http://www.omg.org/technology/documents/formal/ocl.htm, 2006 [OMG06b] Diagram Interchange Spezifikation, Version 1.0, http://www.omg.org/docs/formal/06-04-04.pdf, 2006 [OMG06c] Meta Object Facility (MOF) Core, v2.0, http://www.omg.org/docs/formal/06-01-01.pdf, 2006 [OMG07] SysML Spezifikation, http://www.omgsysml.org/ [OMG07b] [SDL07] [TPC07] UML Spezifikation, http://www.uml.org/ Specification and Description Language, http://de.wikipedia.org/wiki/specification_and_description_langua ge, 2007 MODELING FRAMEWORK - Tutorial : Generate an Editor, http://topcasedmm.gforge.enseeiht.fr/website/modeling/tutorials/generateeditor.htm l, 2007 [TPC07b] Newsgroup TOPCASED, http://lists.gforge.enseeiht.fr/pipermail/topcased-mm-users/, 2007 [TWE06] Tim Weilkiens, Systems Engineering mit SysML/UML, dpunkt Verlag, 2006 [WIK07] EBNF Wikipedia-Artikel, http://de.wikipedia.org/wiki/ebnf [WIF07] Website Ingenieurbüro Dr. Kahlert, http://www.kahlert.com, 2007