MontiCore: Agile Entwicklung von domänenspezifischen Sprachen ...
MontiCore: Agile Entwicklung von domänenspezifischen Sprachen ...
MontiCore: Agile Entwicklung von domänenspezifischen Sprachen ...
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
1.2 Domänenspezifische <strong>Sprachen</strong> 7<br />
Statecharts<br />
C++,<br />
Java …<br />
Sequenzdiagramme<br />
Objektdiagramme<br />
__: __:<br />
Klassendiagramme<br />
Verteilungsdiagramme<br />
DSLs<br />
OCL<br />
__:<br />
Konsistenzanalysator<br />
Parametrisierter<br />
Codegenerator<br />
Testcodegenerator<br />
„Smells“ /<br />
Fehler<br />
System<br />
Tests<br />
Abbildung 1.1: <strong>Agile</strong> modellgetriebene <strong>Entwicklung</strong> (adaptiert aus [Rum04a])<br />
Modelle werden im Laufe der <strong>Entwicklung</strong> fortlaufend verfeinert, konkretisiert und an<br />
neue Anforderungen angepasst.<br />
Diese Form der <strong>Entwicklung</strong> korrespondiert gut mit den agilen Methoden auf Quellcodeebene,<br />
weil weniger explizite Planungsdokumente existieren, sondern viele der erstellten Artefakte<br />
direkt Teil der Lösung sind. Im Sinne einer ausführbaren Spezifikation beeinflussen<br />
die Modelle direkt die Software. Die Modelle sind eine Form der Spezifikation, die jedoch<br />
automatisch in Code umgesetzt werden kann. Daher wird oftmals auch <strong>von</strong> „Correct-bydesign“<br />
gesprochen, weil die entstehende Software direkt aus der Spezifikation umgesetzt<br />
wird und ihr somit automatisch entspricht, sofern der Generator korrekt implementiert<br />
ist. Dadurch wird eine Verifikation der Software unnötig, aber die Validierung gewinnt<br />
an Bedeutung, insbesondere weil der Entwickler, der vorher die Modelle manuell umgesetzt<br />
hat, als eine kritisch kontrollierende Instanz entfällt. Daher kann es, wie in [Rum04a]<br />
beschrieben wird, sinnvoll sein, explizite Testmodelle zu verwenden, die den modellierten<br />
Sachverhalt aus einem anderen Blickwinkel betrachten. Durch diese neu eingeführte<br />
Redundanz lassen sich Fehler während der <strong>Entwicklung</strong>sphase entdecken.<br />
1.2 Domänenspezifische <strong>Sprachen</strong><br />
Innerhalb der Literatur gibt es keine einheitlich akzeptierte Definition, was unter einer<br />
domänenspezifischen Sprache zu verstehen ist. Einige häufig zitierte Beispiele sind die<br />
folgenden Definitionen:<br />
• „DSLs show an increased correspondence of language constructs to domain concepts<br />
when contrasted with general purpose languages [...] [and are] often computationally<br />
incomplete.“ [KPKP06]<br />
• „A DSL is a language designed to be useful for a limited set of tasks, in contrast<br />
to general-purpose languages that are supposed to be useful for much more generic<br />
tasks, crossing multiple application domains.“ [JB06]
Change language