download - SPES 2020

Zusammenfassendes Deliverable D2.1C: 

SysML Profil für Enterprise Architect 

zur Modellierung modellbasierter Anforderungen im SPES- 

Requirements View 

Projektbezeichnung SPES 2020 

Verantwortlich Bastian Tenbergen 

Version: 1.0 

QS-Verantwortlich Siehe Teilergebnisse im Anhang 

Erstellt am 11.04.2011 

Zuletzt geändert 06.06.2011 15:24 

Freigabestatus Vertraulich für Partner: ; ; … 

Projektöffentlich 

X Öffentlich 

Bearbeitungszustand in Bearbeitung 

vorgelegt 

X fertig gestellt

Weitere Produktinformationen 

Erzeugung Sebastian Gabrisch (SG), Bastian Tenbergen (BT) 

Mitwirkend Thorsten Weyer (TW), Heiko Stallbaum (HS), weitere siehe Teilergebnisse 

Änderungsverzeichnis 

Änderung 

Nr. Datum Version 

Geänderte 

Kapitel 

Beschreibung der Änderung Autor Zustand 

1 11.04.11 0.1 Alle Initiale Produkterstellung SG In Bearbeitung 

2 27.04.11 0.2 Alle Inhaltliche Vervollständigung BT In Bearbeitung 

3 17.05.11 0.3 Alle Inhaltliche Vervollständigung SG In Bearbeitung 

4 25.05.11 0.4 Alle Inhaltliche Überarbeitung BT In Bearbeitung 

5 29.05.11 0.5 Alle Überarbeitung und Korrektur BT In Bearbeitung 

6 03.06.11 0.6 Alle Editorielle Überarbeitung SG In Bearbeitung 

7 06.06.11 1.0 Alle Internes Review und Finalisierung 

BT/HS Fertig gestellt

Kurzfassung 

In diesem Ergebnisdokument wird das integrierte Gesamtprofil zur Spezifikation modellbasierter 

Anforderungen anhand des in ZP-AP2 entwickelten modellbasierten 

RE-Ansatzes beschrieben. Zusammen mit der Beschreibung des modifizierten RE- 

Ansatzes [SPES11e] stellt dieses Profil die Grundlage für die in [SPES11f] beschriebene 

Sicht auf das Requirements Engineering (dem sogenannten Requirements 

View) der SPES-Methodik dar. Bei diesem Dokument handelt es sich um eine Zusammenfassung, 

welche die bisher erstellten drei Einzelprofile zur Ziel- und Szenariomodellierung 

und zur Modellierung lösungsorientierter Anforderungen zusammenfasst 

und erweitert. Diese Modelle wurden einzeln bereits schon in den drei vorigen 

Teilergebnissen [SPES11b], [SPES11c] und [SPES11d] vorgestellt und in Enterprise 

Architect implementiert. Mit dem in diesem Dokument beschriebenen einheitlichen 

EA-Profil soll nun eine Grundlage der werkzeugbasierten Unterstützung für die prototypische 

Verwendung des initialen modellbasierten RE-Ansatzes erstellt werden. Zudem 

wird in diesem Deliverable das Teilergebnis zum Stand der Praxis der domänenspezifischen 

Sprachenentwicklung zusammenfasst, welches Grundlage für die 

Erstellung der separaten Einzelprofile war. 

Zuletzt geändert: 06.06.2011 15:24 3/34

Inhalt 

1 Einordnung und Kurzbeschreibung ............................................................... 5 

1.1 Motivation und Einordnung ..................................................................... 5 

1.2 Management Summary ........................................................................... 5 

1.3 Überblick ................................................................................................. 5 

2 Überblick über verwendete Modelle und Erweiterung des initialen Ansatzes 7 

2.1 Zielmodellierung ...................................................................................... 7 

2.2 Szenariomodellierung ............................................................................. 8 

2.3 Modellierung lösungsorientierter Anforderungen .................................... 9 

2.4 Erweiterungen gegenüber dem initialen Ansatz .................................... 11 

3 Modellunterstützung für den Requirements View ........................................ 13 

3.1 „State of the Art“ bei der domänenspezifischen Modellierung ............... 13 

3.2 Zusammenfassung ............................................................................... 14 

4 Vorgehen bei der Erstellung der Einzelprofile ............................................. 16 

4.1 Schritt 1: Modellieren der Domäne nach dem Requirements View ....... 16 

4.2 Schritt 2: Verbesserung und Komplettierung des Domänen-modelles .. 17 

4.3 Schritt 3: Übertragen der Methodenkonzepte in das UML/SysML 

Metamodell ........................................................................................................... 18 

4.4 Schritt 4: Definition fehlender Stereotypen ............................................ 19 

5 Das Gesamtprofil SysML-Profil ................................................................... 21 

5.1 Erstellung des Enterprise Architect-Profils ............................................ 21 

5.2 Überblick über das Enterprise Architect-Profil ...................................... 22 

6 Kurzanleitung: Installation und Verwendung des Profils .............................. 26 

6.1 Installation der MDG-Technologie ......................................................... 26 

6.2 Verwendung des Profils ........................................................................ 26 

6.3 Erweiterung des Profils ......................................................................... 27 

7 Zusammenfassung ...................................................................................... 28 

8 Referenzen .................................................................................................. 29 


1 Einordnung und Kurzbeschreibung 

In diesem Abschnitt wird eine kurze Einordnung in den Projektkontext beschrieben 

und ein Überblick über den Dokumenteninhalt gegeben. 

1.1 Motivation und Einordnung 

Das vorliegende Ergebnisdokument beschreibt den Prozess der Erstellung eines 

Gesamtprofiles für das Modellbasierte Requirements Engineering (MBRE) als Enterprise 

Architect Plug-In. Dieses Dokument beschreibt den grundlegenden Aufbau des 

Plug-Ins aus den drei Teilergebnissen (siehe [SPES11b], [SPES11c] und 

[SPES11d]) sowie die Änderungen gegenüber den Einzelprofilen. Ziel des integrierten 

Gesamtprofils ist die grundlegende Werkzeugunterstützung für den initialen, modellbasierten 

RE-Ansatz. Zudem beschreibt dieses Dokument die der Erstellung der 

Einzelprofile vorangegangene Aufarbeitung des Standes der Wissenschaft hinsichtlich 

der Entwicklung domänen- bzw. methodenspezifischer Sprachen und das darauf 

aufbauende Vorgehen bei der Entwicklung der Einzelprofile. 

1.2 Management Summary 

In diesem Dokument wird das integrierte Gesamtprofil für die modellbasierte Spezifikation 

von Anforderungen anhand der von ZP-AP2 vorgestellten Requirements- 

Engineering-Methodik beschrieben, welches die bisher erstellten drei Einzelprofile 

zusammenfasst und erweitert. Die Einzelprofile wurden im Rahmen der Ausarbeitung 

zweier Fallstudien im Vorfeld in Kooperation mit Bosch und EADS entwickelt, nachdem 

eine Untersuchung des Standes der Praxis bzgl. des modellbasierten Requirements 

Engineering ergab, dass eine durchgehende Unterstützung in einem kommerziellen 

Entwicklungswerkzeug für die Anwendbarkeit eines neuen, RE-Ansatzes unabdingbar 

ist [STP11]. 

Das Profil basiert auf den Ausführungen aus dem initialen, modellbasierten Requirements 

Engineering Ansatz für Embedded Systems zu einem durchgehenden Modellbasierten 

Vorgehen im Entwicklungsprozess. Die Modelle umfassen die Zielmodellierung 

als Grundlage für die systematische Erhebung und Verfeinerung von Anforderungen, 

die Szenariomodellierung durch Use-Cases und Sequenzdiagramme zur 

Erhebung und Verfeinerung von Anforderungen auf mehreren Abstraktionsebenen 

und zur Konkretisierung von Zielen, sowie lösungsorientierten Anforderungen zur 

strukturierten Modellierung der durch Ziele und Szenarien erhobenen Anforderungen. 

Darüber hinaus lassen sich statisch-strukturelle Diagramme (beispielsweise die Datenperspektive 

lösungsorientierter Anforderungen [Pohl10], Architekturmodelle und 

auch der dem RE-Ansatz hinzugefügten Anforderungsartefakttypen „Umwelt“ 

[SPES11e]) mit Hilfe des in diesem Dokument beschriebenen Profils modellieren. 

Mit einem einheitlichen EA-Profil wird die werkzeugbasierte Unterstützung zur Modellierung 

von Anforderungen ermöglicht, sodass der Requirements View [SPES11f] der 

SPES-Methodik werkzeugseitig verwendet werden kann. 

1.3 Überblick 

Kapitel 2 erläutert die Methoden, die für den Requirements View relevant sind und im 

Gesamtprofil konsolidiert wurden. Ferner werden die Erweiterungen des Gesamtprofiles 

gegenüber dem initialen Ansatzes [SPES09a] beschrieben. In Kapitel 3 wird der 

Stand der Wissenschaft zur Entwicklung domänenspezifischer Sprachen bzgl. der 

Anwendung auf ein methodenspezifisches Profil, welches die in Kapitel 2 beschrie- 


enen Modelle in einem integrierten Requirements View beinhalten soll, zusammengefasst. 

Kapitel 4 beschreibt, wie bei der Erstellung des methodenspezifischen Gesamtprofils 

auf dem in Kapitel 3 beschriebenen Stand der Wissenschaft aufbauend, 

vorgegangen wurde. Kapitel 5 beschreibt im Detail das SysML-Profil für Enterprise 

Architect des Requirements Views der SPES-Methode, wie es aus den Teilergebnissen 

zusammengesetzt wurde und die dort enthaltenen einzelnen Pakete. Kapitel 6 

enthält eine Kurzanleitung zur Verwendung und Installation des Profils in Enterprise 

Architect. Eine Zusammenfassung dieses Dokumentes kann Kapitel 7 entnommen 

werden. 


2 Überblick über verwendete Modelle und Erweiterung 

des initialen Ansatzes 

Die im initialen Ansatz vorgestellten Modelltypen (Zielmodelle, Szenariomodelle und 

lösungsorientierte Modelle) bieten Modellierungstechniken für alle Entwicklungsphasen, 

von der Vision des Systems bis hin zu konkreten Implementierungsdetails. Damit 

unterstützen sie das Ziel des in SPES 2010 entwickelten Requirements- 

Engineering-Ansatzes, einen durchgehend modellbasierten Entwicklungsprozess zu 

ermöglichen [SPES09a]. Die drei Modelltypen werden in diesem Kapitel kurz zusammengefasst. 

Detailliertere Ausführung lassen sich den Teilergebnissen 

[SPES11b], [SPES11c], [SPES11d] sowie [Pohl10] entnehmen. 

2.1 Zielmodellierung 

Ziele beschreiben im Requirements Engineering Prozess die von den Stakeholdern 

gewünschten funktionalen und qualitativen Eigenschaften des zu entwickelnden Systems. 

Durch Zielmodelle lassen sich die Ziele und deren Abhängigkeiten beschreiben 

und dadurch bereits in frühen Entwicklungsphasen mögliche Konflikte und alternative 

Lösungsmöglichkeiten identifizieren. Außerdem lassen sich nachfolgende Anforderungs- 

und Entwicklungsartefakte durch das Zielmodell begründen. Die Definition von 

Zielen ist dabei zunächst unabhängig von einer möglichen oder intendierten Systemlösung. 

Abbildung 1: Beispiel für ein Zielmodell [SPES09a] 


Ein vollständiges Zielmodell besteht aus einem graphischen Modell in dem die Beziehungen 

der Ziele zueinander modelliert werden, sowie aus detaillierten, schablonenbasierten 

Beschreibungen der einzelnen Ziele. Im initialen Ansatz wurde für die 

grafische Notation das KAOS-Modell nach [VaLa09] verwendet. Ein Beispiel für diese 

Notation wird in Abbildung 1 gezeigt. Weitere Details zur Modellierung von Zielen 

mit KAOS und schablonenbasierten Beschreibungen finden sich in [SPES09a], 

[SPES11b], und in [Pohl10]. 

2.2 Szenariomodellierung 

Szenarien beschreiben eine Folge von Interaktionen zwischen dem System und dessen 

Umgebung (zum Beispiel anderen Systemen oder Personen) bzw. zwischen einer 

Systemkomponente und Entitäten in ihrer Umgebung. Szenarien können dabei 

mehrere Aspekte der Erfüllung eines Systemzieles modellieren (Erfüllung, Nichterfüllung 

oder nicht beabsichtigte Nutzung). Logisch zusammengehörige Szenarien werden 

häufig zu Anwendungsfällen (engl. Use Cases) gruppiert. Ein Anwendungsfall 

umfasst dabei ein Hauptszenario, mehrere Alternativszenarien sowie mehrere Fehlerszenarien. 

Ein Szenariomodell im Sinne des essenziellen Leitfadens [SPES09a] 

besteht aus einem Anwendungsfalldiagramm, schablonenbasierten Beschreibungen 

der einzelnen Anwendungsfälle, sowie einer modellbasierten Spezifikation der einzelnen 

Anwendungsfallszenarien. Dort werden neben Anwendungsfalldiagrammen 

und Schablonen auch UML/SysML-Sequenzdiagramme verwendet. Ausführlichere 

Informationen zu den verwendeten Modellen finden sich in [SPES09a] und 

[SPES11c], sowie in [Pohl10]. Abbildung 2 zeigt ein Beispiel für ein durch ein Use 

Case Diagramm, eine Schablone und ein Sequenzdiagramm spezifiziertes Szenario. 

Abbildung 2: Beispiel für ein Szenariomodell [SPES09a] 


2.3 Modellierung lösungsorientierter Anforderungen 

Lösungsorientierte Anforderungsmodelle dienen der detaillierten Spezifikation von 

Anforderungen für die nachgelagerten Entwicklungsaktivitäten wie beispielsweise die 

Erstellung der Systemarchitektur, Komponentenentwicklung und Tests des Systems. 

Die Gesamtmenge der lösungsorientierten Anforderungen sollte dabei im Hinblick 

auf die Realisierung des Systems möglichst vollständig, präzise und widerspruchsfrei 

sein (siehe [Pohl10]). Dabei werden in der modellbasierten Variante lösungsorientierter 

Anforderungen drei Perspektiven auf das zu entwickelnde System unterschieden: 

die Daten- bzw. Strukturperspektive, die Funktionsperspektive und die Verhaltensperspektive 

[Davis93]. Abhängig von der Perspektive werden unterschiedliche Modellierungssprachen 

zur Dokumentation der Anforderungen eingesetzt: Datenmodelle, 

wie SysML Blockdiagramme, Verhaltensmodelle, wie Automatenmodelle oder 

SysML State Machine Diagramme und Funktionsmodelle, wie Datenflussdiagramme 

oder SysML Aktivitätsdiagramme. 

Datenmodelle dokumentieren Anforderungen vorrangig aus der Datenperspektive. 

Diese Perspektive wird durch Strukturdiagramme repräsentiert, welche die die statischen 

Strukturen des Systems darstellen, wie z.B. (Daten-)Entitäten, sowie deren 

Attribute und Verbindungen. Im initialen Ansatz werden dazu SysML Blockdiagramme 

verwendet, die auf den Modellelementen des UML-Klassendiagrammes basieren. 

Abbildung 3 zeigt ein SysML Internal Block Diagramm als Beispiel für ein Datenmodell. 

Abbildung 3: Ein SysML Internal Block Diagramm als Beispiel für ein Datenmodell 

[SPES09a] 

Verhaltensmodelle dokumentieren Anforderungen vorrangig aus der Verhaltensperspektive. 

Zur Repräsentation dieser Perspektive wurden im initialen Ansatz SysML 

State Machine Diagramme als Modellierungskonstrukt gewählt. Die SysML State 

Machine Diagramme und wurden aus der UML-Spezifikation übernommen (vgl. 

[OMG10a] und [OMG10b]). Sie stellen erweiterte Automatenmodelle dar, mit Möglichkeiten 

zur Definition von Ereignissen und Bedingungen für Zustandsübergänge, 

zur Modellierung von Nebenläufigkeit und hierarchischer Zerlegung zur Komplexitätsredizierung. 

Abbildung 4 zeigt ein solches Modell. 


stm 2.2.3.1. States "Transportation Controller" 

Initial 

Final 

OperationOn 

Initial 

Automatic Mode 

AutoMode 

!OperationOn 

Activ ated 

Deactiv ated 

OperationOn 

!AutoMode 

Manual Mode 

Abbildung 4: Ein SysML State Machine Diagramm als Beispiel für ein Verhaltensmodell 

[SPES11f] 

Funktionsmodelle dokumentieren Anforderungen primär aus der Funktionsperspektive. 

Die Modellierung dieser Perspektive wird im initialen Ansatz durch Aktivitätsdiagramme 

umgesetzt. Diese modellieren den Kontrollfluss zwischen diskreten und (in 

begrenztem Maße) kontinuierlichen sowie konkurrenten Aktivitäten eines Systems 

mit auf der Abfolge der Aktivitäten sowie auf den Daten- und Objektflüssen zwischen 

den Aktivitäten. Abbildung 5 zeigt ein Funktionsmodell. 

act 2.2.3.2 Functions "Transportation Controller" 

Automatic 

Mode 

Sensor 

Operation 

On 

Automatic 

Mode 

Sensor 

Process Sensor Data 

Functions of Transportation Controller 

Movement 

Instruction Crane1 

Operation On 

Movement 


Movement 


Operation 

On 

Compute Waypoint for 

Crane1 

Compute Waypoint for 

Crane2 

Movement 


Compute Mov ement of 

Conv eyor 

SupplyConveyor 

DeliveryConveyor 

Abbildung 5: Ein SysML Aktivitätsdiagramm als Beispiel für ein Funktionsmodell [SPES11f] 

Zuletzt geändert: 06.06.2011 15:24 10/34 

Crane1 

Action 

Crane2 

Action 

Crane1 

Action 

Crane2 

Action 

SupplyConveyor 

DeliveryConveyor

Ausführlichere Erläuterungen zu den drei oben genannten Modellarten finden sich im 

initialen Ansatz [SPES09a], in [SPES11d] sowie in [Pohl10]. 

2.4 Erweiterungen gegenüber dem initialen Ansatz 

Bei der Entwicklung des vollständigen SysML-Profiles wurden einige Verbesserungs- 

bzw. Erweiterungsmöglichkeiten für den initialen Ansatz identifiziert, welche die methodischen 

Ansätze bei der Modellierung lösungsorientierter Anforderungen betrafen, 

insbesondere die Modellierung der Einbettung des Systems in dessen Kontext (siehe 

[SPES09a] Kapitel 3.1.4.a, sowie Teilaktivitäten 2-1/2-2). Wie bereits in den Studien 

im Vorfeld der Verfassung des initialen Ansatzes bemerkt (z.B. [STP11]) nimmt die 

Komplexität der Beziehungen von softwareintensiven Systemen und deren Anforderungen 

mit der Systemumgebung stetig zu. Dies führte zu der Entscheidung, im Requirements 

View gegenüber dem initialen Ansatz und dem Profil im Teilergebnis 

[SPES11d], explizite Modelle für die System-Umwelt einzuführen. Darüber hinaus 

wurde, um der steigenden Komplexität der Systeme zu begegnen, ein Diagramm 

zum Überblick über die Systemarchitektur eingeführt. Diese Erweiterungen werden 

im Teilbereich der Datenmodellierung durch die Modifikation der Klasse des Strukturdiagrammes 

realisiert. Somit lassen sich mit den bereits vorhandenen und im Teilergebnis 

genutzten Modellelementen des internen Blockdiagrammes Umwelt- und 

Architekturüberblicksartefakte explizit modellieren. 

Abbildung 6: Ein SysML Internal Block Diagramm als Beispiel für ein Umweltmodell 

[SPES11f] 

2.4.1 Das Umweltdiagramm und der Artefakttyp „Umwelt“ 

Im neu kombinierten Paket, welches zur Modellierung von statisch-strukturellen Eigenschaften 

sowie der Architektur und der Umwelt des Systems dient, stellt der Arte- 


fakttyp Umwelt die oben geforderte Darstellung der Einbettung des Systems in seinen 

Kontext dar. Unter Verwendung des Umweltdiagrammes wird die Interaktion des 

Systems mit den Entitäten im operationellen Kontext (sogenannte Kontextentitäten) 

modelliert, dabei kann es sich um andere Systeme (sowohl innerhalb eines größeren 

Gesamtmodells, als auch externe Systeme) oder um Stakeholder des Systems wie 

z.B. die Nutzer handeln. Das zu modellierende System selbst wird hierbei als Black 

Box betrachtet. Das Diagramm nutzt hierbei dieselben Modellelemente wie das in 

Teilergebnis [SPES11d] vorgestellte SysML Internal Block Diagramm. Abbildung 6 

zeigt ein solches Umweltmodell. 

2.4.2 Das Architekturüberblicksdiagramm 

Mit diesem Modell soll ein Überblick über Architekturentscheidungen aufgezeigt werden, 

die im RE-Prozess getroffen wurden. Hierbei werden ebenfalls dieselben Modellelemente 

verwendet wie im Teilergebnis [SPES11d] vorgestellten SysML Internal 

Block Diagramm. Abbildung 7 zeigt ein solches Diagramm. 

Abbildung 7: Ein SysML Internal Block Diagramm als Beispiel für ein Achritektur- 

Überblicksmodell [SPES11f] 


3 Modellunterstützung für den Requirements View 

Das Ziel des im Rahmen von SPES 2010 zu entwickelnden Requirements- 

Engineering-Ansatzes ist es, die Grundlage für einen durchgehend modellbasierten 

Entwicklungsprozess für eingebettete Systeme zu bilden. Für diesen Zweck baut der 

RE-Ansatz auf zwei Lösungskonzepten auf: Einem Abstraktionsebenenmodell 

[SPES11e] und einem Artefaktmodell (siehe [SPES09a] and [SPES11e]). Das Anforderungsartefaktmodell 

basiert auf Modellen, welche auf die spezifischen Erfordernisse 

der frühen Phasen der Systementwicklung zugeschnitten sind, indem sie die Definition 

der lösungsneutralen und lösungsorientierten Anforderungsartefakte unterstützen 

und so den Architekturentwurf fördern. 

In [SPES09a] wurde bereits ein initialer modellbasierter Requirements-Engineering- 

Ansatz verfasst, der eine methodische Unterstützung für die durchgehende Modellierung 

von lösungsneutralen Zielen und Szenarien sowie lösungsorientierten Anforderungen 

in den Perspektiven „Daten“, „Verhalten“ und „Funktion“ [Davis93] über mehrere 

Abstraktionsebenen hinweg erlaubt. Der Ansatz wurde in Industriekooperationen 

[SiPo10] und Fallstudien angewendet, evaluiert und zum Requirements View 

[SPES11f] weiter entwickelt. Dabei stellte sich heraus, dass für eine prototypische 

Verwendung des Ansatzes methodenbezogene Modellierungssprachen und insbesondere 

eine geeignete Werkzeugunterstützung fehlt (vgl. [SPES10b]). Die Bereitstellung 

einer Werkzeugunterstützung ist derzeit Gegenstand von laufenden Arbeiten. 

Gegenstand der in diesem Dokument vorgestellten Arbeit ist die Entwicklung 

einer methodenspezifischen Modellierungssprache, welche die Grundlage für die 

weiterführende Werkzeugunterstützung darstellt. Zur systematischen Erstellung einer 

solchen methoden-spezifischen Modellierungssprache wurde zunächst der Stand der 

Wissenschaft zu domänenspezifischen Sprachen aufbereitet. Die wesentlichen Erkenntnisse 

aus dieser Untersuchung sind im Folgenden darstellt; Details können 

[SPES11aSPES11b] (im Anhang A) entnommen werden. 

3.1 „State of the Art“ bei der domänenspezifischen Modellierung 

Für die domänenspezifische Modellierung wird in der gängigen Fachliteratur gemeinhin 

zwischen domänenspezifischen Modellierungssprachen (Domain-specific modeling 

languages, DSML) und domänenspezifischen Profilen für UML bzw. SysML unterschieden 

(siehe [SPES11a] und Anhang A). DSMLs sind neuartige, bzw. neu zu 

entwickelnde und ausschließlich in der gegebenen Domäne relevante Modellierungssprachen 

(vgl. Kelly und Torvanen [KeTo08]). UML/SysML Profile erweitern 

lediglich das UML Metamodell um einige domänenspezifische Konstrukte und stellen 

einen Mechanismus dar, um domänenspezifische Sprachen basierend auf 

UML/SysML zu definieren (z.B. Lagarde et al. [LETG07]). Im Folgenden werden diese 

beiden Auffassungen und deren grundsätzlich unterschiedlichen Herangehensweise 

in Kürze vorgestellt. Der Begriff „Domäne“ wird im Forschungsfeld der domänenspezifischen 

Sprachen äquivalent zum Begriff „Anwendungsgebiet“ des SPES- 

Projektes verwendet. Es ist allerdings zu bemerken, dass die „Domäne“ im Kontext 

methodenspezifischer Werkzeugunterstützung die Methode selber ist, für die die 

Werkzeugunterstützung angestrebt wird. Allerdings lassen sich die Erkenntnisse bei 

der Erstellung domänenspezifischer Sprachen auf die Erstellung methodenspezifischer 

Sprachen übertragen. 

3.1.1 Domänenspezifische Modellierungssprachen 

Domänenspezifische Modellierungssprachen (DSMLs) sind speziell zu entwickelnde 

Sprachen, die in einer gegebenen spezifischen Domäne die Sachverhalte und deren 


Zusammenhänge so exakt wie möglich abbilden sollen. Dabei bildet die DSML das 

„spezifische Wissen“, die Konzepte und zum großen Teil auch die „Best Practices“ 

innerhalb dieser Domäne ab. Damit wird in der Regel die typische Art und Weise, wie 

in dieser Domäne Modellartefakte entwickelt werden nachgebildet und in gleicher 

Weise unterstützt (siehe [KeTo08] und [SPES11a]). Ein Nachteil der Einführung einer 

neuen DSML ist, dass gängige, auf dem Markt erhältliche Modellierungswerkzeuge 

in der Regel nicht für die neu entwickelte Sprache verwendet werden können, da die 

neu entwickelte DSML ggf. Konzepte enthalten könnte, die in einem kommerziellen 

Werkzeug nicht berücksichtigt werden. Domänenexperten sind daher darauf angewiesen, 

eine Werkzeugunterstützung zusammen mit der DSML zu entwickeln. Diese 

Entwicklung sowie die Einarbeitung der Mitarbeiter in das Werkzeug und die DSML 

verbraucht Zeit und Ressourcen. In [SPES11a] werden neben einer etwas detaillierteren 

Beschreibung von DSMLs im Allgemeinen auch zwei Ansätze zur Entwicklung 

einer DSML im Detail anhand einiger Beispiele vorgestellt. 

3.1.2 UML/SysML-Profile 

Eine andere Möglichkeit eine DSML zu entwickeln, ist durch den UML- 

Profilmechanismus gegeben. Dieser ermöglicht die Definition domänenspezifischer 

Erweiterungen des UML/SysML-Metamodelles bzw. dort bestehender Modellelemente. 

Diese Erweiterungen werden in einem UML/SysML-Profil festgelegt. Die Erstellung 

eines solchen domänenspezifischen UML/SysML-Profils kann möglicherweise 

mehr Aufwand erzeugen als die Entwicklung einer eigenen DSML, da die spezifischen 

Eigenschaften der UML, wie Aufbau und Struktur sowie vorhandene Modellelemente 

berücksichtigt werden müssen und auf Konsistenz zur Meta-Object Facility 

[OMG11a], dem UML/SysML Metamodell, geachtet werden muss. Dies kann 

unter Umständen auch darin resultieren, dass einige Konzepte der Domäne sich 

nicht exakt den vorliegenden UML-Metamodellelementen zuordnen lassen. Der Vorteil 

bei der Verwendung von UML-Profilen ist, dass existierende kommerzielle Werkzeuge 

für UML/SysML-Profile wiederverwendet werden können, da die Profile auf 

dem gleichen Metamodell aufbauen, wie UML und SysML, und dieses bereits im 

Werkzeug berücksichtigt sind. Des Weiteren ist der Lernaufwand für Sprache und 

Werkzeug bei der Anwendung von domänenspezifischen Profilen im Gegensatz zu 

einer komplett neu entwickelten DSML erheblich reduziert, da die Anwender mit Erfahrung 

in UML oder SysML ihr Vorwissen bei der Anwendung des Profils wiederverwenden 

können. In [SPES11a] werden drei Ansätze zur Entwicklung von domänenspezifischen 

UML/SysML-Profilen vorgestellt. 

3.2 Zusammenfassung 

Mit UML-Profilen wird ein Mechanismus bereitgestellt, um das UML/SysML- 

Metamodell domänenspezifisch zu erweitern, und somit die Grundlage für prototypische 

Methodenunterstützung zu legen. UML-Profile bieten somit eine verhältnismäßig 

einfache Möglichkeit, Werkzeugunterstützung zu realisieren, wenn die Konzepte 

der Domäne sich auf UML bzw. SysML übertragen lassen. Außerdem wurde in der 

Erhebung zum Stand der Praxis des modellbasierten Requirements Engineering 

[SPES10a] festgestellt, dass insbesondere UML und SysML in der Industrie für modellbasierte 

Entwicklungsaktivitäten häufig Verwendung findet. Die in [SPES10b] erhobenen 

Anforderungen der Industrie an einen durchgehenden modellbasierten RE- 

Ansatz schließen unter anderem die Verwendung methodenspezifischer Modellierungssprachen 

ein. So wird auch Konformität zu UML und insbesondere zu SysML 

explizit gefordert. Daher wird zur methodenbezogenen Werkzeugunterstützung des 

initialen Ansatzes ein UML/SysML-Profil für Enterprise Architect entwickelt. Ferner 


wird hierdurch sichergestellt, dass die somit resultierende methodenspezifische 

Sprache mit kommerziellen Modellierungswerkzeugen verwendbar ist. Im folgenden 

Kapitel 0 wird die Methode vorgestellt, die auf den in [SPES11a] gewonnenen Erkenntnissen 

aufbaut. 


4 Vorgehen bei der Erstellung der Einzelprofile 

In diesem Kapitel wird das Vorgehen beschrieben nach dem die Einzelprofile und 

das konsolidierte Gesamtprofil für den Requirements View erstellt wurden. Das hier 

beschriebene Vorgehen stützt sich auf die in [LETA08] vorgeschlagene Methode und 

würde für die Anwendung auf eine methodenspezifische Sprache anstelle einer domänenspezifischen 

Sprache angepasst. 

4.1 Schritt 1: Modellieren der Domäne nach dem Requirements 

View 

Der erste Schritt zum konsolidierten Gesamtprofil war die Modellierung der Domäne 

“eingebettete Systeme” nach dem überarbeiteten Requirements View in Enterprise 

Architect. Abbildung 8 zeigt das Ergebnis dieses ersten Schrittes. Das Konzept „System“ 

ist der Mittelpunkt des Requirements View, es stellt das System welches betrachtet 

wird dar. Wie bereits in Abschnitt 2 dargestellt, sind die Konzepte der Ziele 

(„Goals“) und Szenarios („Scenarios“) als Artefakttypen im Requirements View enthalten. 

Der Artefakttyp Lösungsorientierte Anforderungen („Solution-Oriented Requirements“) 

wurde in seinen drei unterschiedlichen Konzepten Funktionsmodell 

(„Function“), Verhaltensmodell („State“) und Datenmodell („Data“) modelliert. Diese 

drei Sichten wurden anstelle eines einzelnen Konzeptes lösungsorientierter Anforderungen 

explizit im Domänenmodell implementiert, da diese drei Konzepte die drei 

Perspektiven eingebetteter Systeme wiedergeben (funktional, zustands- und datenorientiert; 

siehe [Pohl10]). Der Requirements View gibt durch den RE-Prozess die 

Beziehungen zwischen den verschiedenen Artefakttypen im Modell vor (siehe 

[SPES09a]). 

Abbildung 8: SysML Block Diagramm für die Domäne eingebetteter Systeme 

nach Schritt 1 

Besondere Aufmerksamkeit wurde der konzeptuellen Unterstützung von Abstraktionsebenen 

gewidmet, wie sie in den Lösungskonzepten des Requirements View gefordert 

werden (siehe Kapitel 3, sowie [SPES11e]). Das Abstraktionsebenenkonzept 

wurde im Domänenmodell durch die Einführung des Konzeptes Subsystem („Sub- 


system“) realisiert, welches vom Konzept System („System“) erbt, sowie Komponente 

(„Component“) welches vom Konzept Subsystem erbt. Durch diese Hierarchie 

im Modell ist es möglich, dass ein System aus beliebig vielen Subsystemen besteht, 

welche wiederum aus beliebig vielen Subsystemen oder Komponenten bestehen 

können. Eine Komponente ist hierbei ein Subsystem, dass nicht weitere in unterschiedliche 

Subsysteme zerlegt werden kann. Der Requirements View Artefakttyp 

Architektur („Architecture“) wurde allerdings nicht als Konzept des Domänenmodells 

dargestellt, da dieser Artefakttyp durch die Vererbungsbeziehungen des Konzeptes 

„System“ ausgedrückt werden kann. 

4.2 Schritt 2: Verbesserung und Komplettierung des Domänenmodelles 

Während der Analyse des Domänenmodells auf Brüche bezüglich seiner Abbildung 

der Realität wurde festgestellt, dass dem erstellten Domänenmodell die Möglichkeit 

zur die Modellierung externer Systeme fehlt. Eingebettete Systeme interagieren in 

der Regel neben dem eigentlichen Systembenutzer mit einer Vielzahl anderer Systeme 

(siehe Kapitel 2.4.1 sowie [STP11]). Daher wurde das Domänenmodell um die 

Möglichkeit erweitert externe Systeme darzustellen, die mit dem zu modellierenden 

System interagieren. 

Abbildung 9: SysML Block Diagramm für die Domäne eingebetteter Systeme mit Korrekturen 

und Änderungen aus Schritt 2. 


Im diesem Problem entgegenzuwirken, wurde das Domänenkonzept Externes System 

(„External System“) definiert, welches von dem Konzept System erbt. Für eine 

Interaktion mit externen Systemen muss das zu modellierende System entsprechende 

Interfaces bieten um Informationen wie z.B. Nachrichten, Signale oder Prozessaufrufe 

senden und empfangen zu können. Daher wurde das Interface Konzept 

ebenfalls in das Domänenmodell eingefügt. Das Domänenkonzept Daten („Data“) 

wurde hierzu in die Konzepte Eingabedaten („Input Data“) und Ausgabedaten 

(„Output Data“) zerlegt. Ein Interface kann hierbei sowohl als Schnittstelle zwischen 

Hardwarekomponenten, als auch zwischen Software, zwischen ganzen Systemen 

oder zwischen Funktionen verstanden werden. Die korrekte Darstellung des Artefakttyp 

„Daten“ bleibt im Domänenmodell trotzdem bestehen, da Interfaces Eingaben 

und/oder Ausgaben modellieren können. Das Ergebnis dieser Änderungen an dem 

Domänenmodell aus Schritt 2 wird in Abbildung 9 dargestellt. 

4.3 Schritt 3: Übertragen der Methodenkonzepte in das 

UML/SysML Metamodell 

In Abbildung 10 werden die existierenden SysML Diagrammtypen gezeigt, die für die 

in Schritt 1 und 2 identifizierten Methodenkonzepte verwendet werden können. Wie 

zu sehen ist können beinahe alle Konzepte („Scenario“, „State“, „Function“ und „Data“) 

mit existierenden SysML-Diagrammtypen ausgedrückt werden. Diese umfassen 

SysML Use-Case Diagramme und Sequenzdiagramme, Statecharts, Aktivitätsdiagramme 

und interne Blockdiagramme. Die hohe Kompatibilität zwischen Requirements 

View und SysML ergibt sich aus der Tatsache, dass der Requirements View 

mit der Absicht definiert wurde, sowohl die Modellierung der drei Perspektiven eingebetteter 

Systeme [Davis93] zu unterstützen, was ebenfalls eine wichtige Rolle bei der 

Entwicklung von UML und SysML spielte (vgl. [OMG10a] und [OMG10b]). 

Abbildung 10: SysML Package Diagramm mit den importierten SysML Diagrammtypen die 

im COSMOD-RE Profil wiederverwendet werden 

Das einzige Konzept welches nicht auf existierende Komponenten der SysML übertragen 

werden konnte ist das des Zieles, da SysML keinen expliziten Mechanismus 

zur Modellierung von Systemzielen besitzt. Da nach dem Requirements View die 

Nutzung des Ziel-Konzeptes explizit gefordert ist, musste dieses Konzept hinzugefügt 

werden. Die Möglichkeit zur Zielmodellierung wurde auf Basis des KAOS- 

Frameworks (vgl. [RespIT07] und [VaLa09]) implementiert, da diese die größte Kom- 


patibilität mit den Methoden des Requirements View aufweist. Eine Überprüfung des 

KAOS Frameworks führte zudem zur Identifizierung einiger weiterer Konzepte, die 

eingeführt werden mussten um die Modellierung von Zielen genau abzudecken. Zu 

diesen Konzepten gehören z.B. Zielverfeinerung („Goal Refinement“), Zielkonflikt 

(„Goal Conflict“) und Zielbeitrag („Goal Contribution“) welche im nun folgenden 

Schritt als neue Stereotypen eigeführt werden. 

4.4 Schritt 4: Definition fehlender Stereotypen 

Abbildung 11 zeigt das komplettierte Profil mit den definierten Stereotypen für die 

Zielmodellierung die in diesem Schritt erstellt wurden. Das einzige Konzept des Domänenmodells, 

das durch die Definition von neuen Stereotypen abgebildet wurde, ist 

das Konzept des Ziels. Dieses Konzept wurde durch die Stereotypen Ziel („Goal“) 

und Zielverfeinerung („Refinement“) implementiert, welche von der Metaklasse 

„Block“ erben. Des Weiteren beinhaltet das Profil den Stereotypen „Refinement of“, 

welcher von der Metaklasse „Generalisierung“ erbt, sowie die Stereotypen „Refined 

by“, „Conflict“ und „Contribution“, welche von der Metaklasse „Association“ erben. 

Ziel bzw. „Goal“ ist hierbei der Haupt-Stereotyp, der das Zielkonzept des Domänenmodells 

abbildet. Obwohl augenscheinlich kompatibel zu der Metaklasse Anforderung 

(bzw. „Requirement“), erbt das hier implementierter Zielkonzept nicht von dieser 

Metaklasse, da dies den Mechanismus der Zielverfeinerung, der im KAOS Framework 

spezifiziert wurde, verletzen würde (siehe [RespIT07] bzw. [VaLa09]). Der Typ 

„Requirement“ spezifiziert Einschränkungen wie beispielsweise die Containment- 

Beziehung, die für KAOS-Ziele nicht gelten. Dem entsprechend werden die „Containment“ 

Beziehungen der Requirement-Metaklasse nicht wiederverwendet, sondern 

durch die neuen Stereotypen „Refinement“ sowie den Assoziationstypen „Refinement_Of“ 

und „Refined_By“ ersetzt. Der Stereotyp Ziel (bzw. “Goal”) kann außerdem 

durch den zugeordneten Tag „Goal Type“, der zu einer Enumeration desselben 

Namens verweist, weiter in „Hard Goals“ und „Soft Goals“ unterschieden werden. 

Abbildung 11: SysML Package Diagram mit neuen Stereotypen für die Zielmodellierung 


Der Stereotyp „Refinement“ kann dazu verwendet werden UND- sowie ODER- 

Beziehungen von Zielen gemäß dem KAOS Framework auszudrücken (siehe 

[VaLa09] für weitere Informationen zur Verfeinerung von Zielen). Dabei wird der Stereotyp 

„Refinement_Of“ genutzt um darzustellen, dass diese Ziele Verfeinerungen 

des Zieles auf der höheren Ebene sind. Der Stereotyp „Refined_By“ wird verwendet 

um alle zu einer Verfeinerungsalternative gehörenden Ziele einem Oberziel zuzuordnen. 

Der Stereotyp „Conflict“ bezeichnet, dass bei zwei Zielen, die mit dieser Assoziation 

versehen sind, die Erfüllung des einen Ziels die des zweiten Ziels verhindert und 

umgekehrt. Der Stereotyp „Contribution“ bezeichnet, dass bei einer Assoziation die 

Erfüllung eines Zieles die des anderen Ziels positiv oder negativ beeinflusst. Diese 

Unterscheidung der Beeinflussung kann durch den zugeordneten Tag „Contribution- 

Type“ beschrieben werden. Details zu Zielbeziehungen können ebenfalls in 

[RespIT07] gefunden werden. 


5 Das Gesamtprofil des Requirements Views 

Zur Bereitstellung einer Werkzeugunterstützung für den Requirements View der 

SPES-Methode wurde ein UML/SysML-Profil für Enterprise Architect entwickelt. In 

diesem Profil werden die drei aus den vorigen Teilergebnissen [SPES11b], 

[SPES11c] und [SPES11d] (siehe Anhang B-D) hervorgegangenen Einzelprofile zur 

Modellierung von Zielen, Szenarien und lösungsorientierten Anforderungen zusammengefasst 

und erweitert (siehe Kapitel 2.4). In diesem Kapitel wird das Gesamtprofil 

im Detail beschrieben. In Kapitel 5.1 wird dabei zunächst die Entwicklung bis hin zu 

dem vereinigten Profil kurz beschrieben und auf die Besonderheiten des Gesamtprofils 

gegenüber den Einzelprofilen eingegangen. In Kapitel 5.2 wird der Inhalt der 

Enterprise-Architect-Projektdatei und der einzelnen Pakete im Detail beschrieben. 

5.1 Erstellung des Enterprise Architect-Profils 

In der UML und der SysML sind Profile eine Erweiterung des UML-Metamodells mit 

denen sich domänenspezifische Modelle und Modellierungssprachen entwickeln lassen. 

In einem UML/SysML-Profil können dabei die die vorgesehenen Erweiterungsmechanismen 

(z.B. Stereotypen und Einschränkungen) des Metamodelles der UML 

sowie Importe bereits vorhandener Metamodellelemente vorkommen, die weiter spezifiziert 

werden können. In Enterprise Architect (EA) werden diese Profile mittels 

MDG-Technologien (Abk. für Model-Driven Generation) implementiert, die für den EA 

lesbar die Erweiterungen für Werkzeugpaletten, UML-Profile, Muster, Vorlagen und 

andere Modellelemente definieren. Diese MDG-Technologien können als Plug-In in 

EA geladen werden und die dort definierten Elemente stehen anschließend für die 

Modellierung zur Verfügung. Im Rahmen der Entwicklung eines vollständigen Profils 

zur geforderten Werkzeugunterstützung des Requirements Views wurden für die einzelnen 

Modellierungsteilgebiete (Ziele, Szenarien und lösungsorientierte Anforderungen) 

zunächst einzelne Teilprofile anhand der in Abschnitt 4 dargestellten Methode 

für EA entwickelt, die die in den entsprechenden Aktivitäten zu verwendenden Modelle 

definieren und beschreiben. 

Das Profil für die Zielmodellierung (siehe [SPES11b]) wurde auf der Basis des 

UML2-Metamodelles [OMG11a] erstellt, da UML/SysML kein Diagramm zur Modellierung 

von Zielen vorsieht. Das Profil für die Zielmodellierung erweitert die UML/SysML 

um die Modellierung von Zielen nach den dafür relevanten Teilen der KAOS- 

Methode. Die Profile für Szenariomodelle [SPES11c] und für lösungsorientierte Anforderungen 

[SPES11d] kommen ohne Einführung neuer Elemente oder Erweiterung 

von Syntax und Semantik der UML/SysML aus. Diese beiden Profile definieren lediglich 

einen neuen Viewpoint und importieren die benötigten Pakete aus dem bereits in 

EA vorhandenen UML/SysML-Profil. 

In dem im folgenden Kapitel 5.2 beschriebenen Gesamtprofil wurden die drei Einzelprofile 

zu einem Gesamtprofil für den Requirements View zusammengefasst. Die 

Besonderheiten gegenüber den Einzelprofilen aus den vorigen Teilergebnissen sind: 

Erweiterung um die expliziten Perspektiven Umwelt und Architekturüberblick 

mit Modellelementen des Datenmodells/internen Blockdiagramms der SysML. 

Platzhalter für spätere Revsionen/Erweiterungen/Einschränkungen des Ansatzes. 

Gemeinsame Definiton der einzelnen Diagrammtypen. 


5.2 Überblick über das Enterprise Architect-Profil 

Im Gesamtprofil des Requirements Views (Siehe Abbildung 12) befinden sich die drei 

Pakete „SysML Goal Modeling“, „SysML Scenario Modeling“ und „SysML Solution- 

Oriented Modeling“. Letzteres enthält wiederum das neu erstellte Paket „SysML Data/Architecture/Environment 

Modeling“, welches die in Kapitel 2.4 beschriebenen Erweiterungen 

um die Architekturübersicht- und Umweltperspektive definiert. 

Abbildung 12: Überblick über das Gesamtprofil 

In Abbildung 12 ist der hierarchische Aufbau des Gesamtprofils mit seinen drei 

Hauptpaketen sowie dem vierten, neu hinzugefügten Paket innerhalb des Paketes 

für lösungsorientierte Anforderungen zu sehen. Die Definition der einzelnen Metaklassen 

der Diagramme und Stereotypen findet sich ebenfalls in diesem Gesamtpaket. 

An dieser Stelle werden außerdem die internen Meta-Klassen von Enterprise 

Architect gezeigt, die durch die jeweiligen, in den Paketen definierten Diagrammtypen, 

erweitert werden. Im Paket „Goal Modeling“ ist das Diagramm zur Zielmodellierung 

mit KAOS („KAOS Goal Modeling“) definiert welches die Metaklasse „Diagram_Logical“ 

erweitert. Im Paket „Scenario Modeling“ finden sich die beiden Dia- 


grammtypen „SysML Use Case Diagram“ und „SysML Sequence Diagram“, welche 

die Metaklassen „Diagram_Use Case“ bzw. „Diagram_Sequence“ erweitern. Im Paket 

Solution-Oriented Modeling sind die beiden Diagrammtypen „SysML State Machine 

Diagram“ und „SysML Activity Diagram“ definiert welche die Metaklassen „Diagram_Statechart“ 

und „Diagram_Activity“ erweitern. Außerdem ist in dem dort enthaltenen 

Paket „Data/Architecture/Environment Modeling“ das „Internal Block Diagram“ 

definiert, welches das „Diagram_Composite Structure“ erweitert. 

Die o.g. Pakete enthalten zudem jeweils drei Pakete vom Stereotyp «Profile», in denen 

jeweils die eigentlichen Diagrammtypen, Modellierungselemente und die Toolboxen 

für den entsprechenden Modellierungstyp definiert werden. Diese werden in 

den folgenden Abschnitten kurz zusammengefasst. 

5.2.1 Das Paket „SysML Goal Modeling“ 

Abbildung 13: Übersicht über das Paket "SysML Goal Modeling" 

In dem in Abbildung 13 dargestellten Paket werden in Einzelprofilen die Elemente 

und Definitionen zur Zielmodellierung in Einklang mit dem initialen Leitfaden festgelegt. 

Darüber hinaus findet sich in dem Paket „Goal Model Example“ ein Beispiel für 

ein Zielmodell. Dieses wurde implementiert, da in diesem Paket eigene Modellierungselemente 

definiert wurden, für die es im SysML-Metamodell keine entsprechenden 

Modellierungsbeispiele gibt. In dem Paket „Goal Modelling Elements“ wird 

ein Ausschnitt der Modellelemente des KAOS-Zielmodelles definiert. Somit implementiert 

dieses Paket die konzeptuelle Erweiterung des UML-Metamodells, wie bereits 

in Abschnitt 4.4 und Abbildung 11 dargestellt (siehe außerdem [Pohl10]). Das 

Paket „Goal Diagram Definition“ enthält das neu definierte Diagramm „KAOS Goal 

Diagramm“ basierend auf dem „Diagram_Logical“. Im Paket „SysML Goal Modeling“ 

wird die zum KAOS Zielmodell gehörende Toolbox für Enterprise Architect definiert. 

Weitere Erläuterungen zu den einzelnen Elementen innerhalb dieses Paketes finden 

sich in dem Teilergebnis [SPES11b]. 


5.2.2 Das Paket „SysML Scenario Modeling“ 

Abbildung 14: Übersicht über das Paket "SysML Scenario Modeling" 

In dem in Abbildung 14 dargestellten Paket werden in drei Einzelprofilen die Elemente 

und Definitionen zur Szenariomodellierung in Einklang mit dem initialen Leitfaden 

[SPES09a] festgelegt. Die Profile „Scenario Modeling Elements“ sowie „SysML Scenario 

Modeling“ sind allerdings leer, da diese nicht die Syntax oder Semantik der 

SysML Use-Case oder Sequenzdiagramme erweitern. Für das Paket „SysML Scenario 

Modeling“ wird lediglich ein neuer Viewpoint für die Szenariomodellierung definiert 

und die passenden bestehenden SysML-Metamodellelemente (Diagram_Sequence 

bzw. Diagram_Use Case) importiert (siehe Abbildung 10). Im Paket SysML Scenaro 

Modeling“ finden sich die beiden neu definierten Diagrammtypen „SysML Sequence 

Diagram“ und „SysML Use Case Diagram“ welche auf den importierten „Diagram_Sequence“ 

sowie „Diagram_Use Case“ basieren. Weitere Erläuterungen zu 

den einzelnen Elementen innerhalb des Paketes finden sich in [SPES11c]. 

5.2.3 Das Paket „SysML Solution-oriented Modeling“ 

Abbildung 15: Übersicht über das Paket "SysML Solution Oriented Modeling" 

Abbildung 16: Übersicht über das Paket "SysML Architecture/Environment Modeling" 

In den Paketen „SysML Solution-Oriented Diagram Definitions“ und „SysML Architecture/Environment 

Diagram Definitions“ (siehe Abbildung 15 und Abbildung 16) werden 

jeweils in drei Einzelprofilen die Elemente und Definitionen zur Modellierung lösungsorientierter 

Anforderungen in Einklang mit dem initialen Leitfaden [SPES09a] 

bzw. dem erweiterten Requirements View [SPES11f] zur Modellierung des neuen 

Modelltyps „Architecture/Environment Modeling“ festgelegt. Die Profile zum „Modeling“ 

(„SysML Solution-Oriented Modeling“ in Abbildung 15 und „SysML Architec- 


ture/Environment Modeling“ in Abbildung 16) bzw. den „Modeling Elements“ („SysML 

Solution-Oriented Modeling Elements“ in Abbildung 15 und „SysML Architecture/Environment 

Modeling Elements“ in Abbildung 16) sind allerdings in beiden Paketen 

leer, da diese nicht die Syntax oder Semantik der SysML Use-Case oder Sequenzdiagramme 

erweitern. Für die Pakete wird lediglich ein neuer Viewpoint für die 

Modellierung lösungsorientierter Anforderungen definiert und die passenden bestehenden 

SysML-Metamodellelemente importiert (Diagram_Statechart und Diagram_Activity 

für die lösungsorientierten Anforderungen bzw. Diagram_Composite 

Structure für das Internal Block Diagram sowie Architecture/Environment Modeling) 

(siehe Abbildung 10). In dem Paket „SysML Solution-Oriented Diagram Definitions“ 

befinden sich die neu definierten Diagramme „SysML Activity Diagram“, „SysML internal 

Block Diagram“ sowie „SysML State Machine Diagram“ basierend auf den importierten 

„Diagram_Activity“ „Diagram_Composite Structure“ und „Diagram_Statechart“. 

Analog findet sich im Paket „SysML Architecture/Environment Diagram 

Definitions“ das in Einklang mit den Erweiterungen des Requirements 

Viewpoint (siehe Kapitel 2.4) neu definierte Diagramm „SysML internal Block Diagram“ 

basierend auf den importierten „Diagram_Composite Structure“. Weitere Erläuterungen 

zu den einzelnen Elementen innerhalb des Paketes finden sich in 

[SPES11d]. 

5.2.4 Das Paket „Domain Model“ 

In dem Paket Domain-Model ist eine Beispiel-Ontologie modelliert für den Requirements 

Viewpoint, auf dessen Basis das Profil erstellt worden ist (vgl. Abschnitt 4.2). 

Das darin enthaltene Domänenmodell ist das verbesserte Domänenmodell, auf dessen 

Grundlage die Einzelprofile erstellt wurden. Das Domänenmodell wurde bereits 

in Abbildung 9 dargestellt. 


6 Kurzanleitung: Installation und Verwendung des Profils 

Das Gesamtprofil des Requirements Views wird in Form eines sogenannten MDG- 

Plug-Ins (siehe [Sparx10]) für Enterprise Architect zur Verfügung gestellt. In diesem 

Abschnitt wird allgemein und in Kürze die Installation, Verwendung und die Erweiterung 

des Profils erläutert. Detailliertere Informationen zur MDG-Technologie, sowie 

zur Verwendung und Erweiterung von UML/SysML-Profilen in Enterprise Architect 

und generell zur Modellierung mit Enterprise Architect werden in [Sparx09] und 

[Sparx10] gegeben. Eine etwas detailliertere Beschreibung und weitere Hinweise zur 

Verwendung der einzelnen Pakete lassen sich falls nötig den Teilergebnissen entnehmen 

(siehe [SPES11b], [SPES11c] [SPES11d]). 

6.1 Installation der MDG-Technologie 

Das MDG-Plug-In befindet sich zusammen mit der Enterprise Architect Projektdatei 

des Profils im ZIP-Archiv. Im Folgenden wird beschrieben, wie solch ein MDG-Profil 

in Enterprise Architect eingebunden werden kann. 

1. Entpacken der ZIP-Datei. Entpacken Sie die ZIP-Datei in einen Ordner auf der lokalen 

Festplatte. Es werden zwei Dateien entpackt: eine EAP- und eine XML-Datei. 

2. Öffnen Sie Enterprise Architect. Starten Sie die Enterprise Architect Anwendung, 

um das MDG-Plug-In einzubinden. 

3. Öffnen Sie den MDG-Technologie-Dialog. Klicken Sie dazu im Enterprise-Architect- 

Menü auf „Settings“ und danach auf die Menüoption „MDG Technologies“. 

4. Definieren Sie einen neuen MDG-Pfad. Im MDG-Technologie-Dialog, klicken Sie 

auf „Advance“ und im darauf folgenden Fenster auf „Add“ und dann auf „Add Path…“. 

Geben Sie den Ordner an, in den Sie die ZIP-Datei in Schritt 1 entpackt haben. Der 

Zielordner ist der Ordner, in dem die XML-Datei entpackt wurde. Klicken Sie anschließend 

auf OK. Enterprise Architect wird Sie darauf hinweisen, dass die Änderungen 

erst nach einem Neustart übernommen werden. 

5. Starten Sie Enterprise Architect neu, um die Änderungen zu übernehmen. 

6. Überprüfen Sie, ob die MDG-Technologie eingebunden ist, indem Sie den MDG- 

Technologie-Dialog wie unter Schritt 4 öffnen. Es sollte nun unter „Technologies“ das 

entsprechende SysML Plug-In aufgeführt werden. 

Weitere Möglichkeiten zur Einbindung von MDG-Plug-Ins in Enterprise Architect sind 

in [Sparx10] erläutert. 

6.2 Verwendung des Profils 

Im Folgenden wird beschrieben, wie das SysML-Profil in Enterprise Architect verwendet 

werden kann. 

1. Erstellen Sie eine neue EA-Projektdatei. Klicken Sie dazu in Enterprise Architect 

auf „File“ und dann „New Project“. Wählen Sie einen geeigneten Pfad und Dateinamen 

für die Projektdatei und klicken Sie auf „speichern“. 

2. Erstellen Sie ein neues Paket unter dem Wurzelknoten „Model“ im „Project Browser“. 

Verwenden Sie dazu entweder die „Add a Package“ oder drücken Sie „Strg+W“. 

Geben Sie dem Projekt einen geeigneten Namen und eine geeignete Sicht auf die 

Modelle, die Sie in diesem Paket erstellen möchten. Klicken Sie anschließend auf 

OK. 

3. Erstellen Sie ein neues Diagramm, indem Sie mit der rechten Maustaste auf das in 

Schritt 2) erstellte Paket klicken und unter dem Menüeintrag „Add“ auf „Add Dia- 


gram…“ klicken. Wählen Sie einen geeigneten Namen für Ihr Zieldiagramm und wählen 

Sie unter „Type“ die entsprechende MDG-Technologie und anschließend unter 

„Diagram Types“ den Eintrag des Diagramms, welches Sie modellieren möchten. 

4. Erstellen Sie ein Diagramm im Enterprise Architect Editor. Genaue Informationen 

zur Verwendung von Enterprise Architect können aus [Sparx09] entnommen werden. 

Weitere Informationen zur Modellierung allgemein und weitere Verweise zu den einzelnen 

Modellen finden sich in [SPES09a] sowie den Teilergebnissen ([SPES11b], 

[SPES11c], [SPES11d]). 

6.3 Erweiterung des Profils 

Im Folgenden wird beschrieben, wie das SysML Solution-Oriented Modeling Profil in 

Enterprise Architect erweitert werden kann. 

1. Entpacken der ZIP-Datei. Entpacken Sie die ZIP-Datei in einen Ordner auf der lokalen 

Festplatte. Es werden zwei Dateien entpackt: eine EAP und eine XML-Datei. 

2. Öffnen Sie die EAP-Datei in Enterprise Architect. Starten Sie die Enterprise Architect 

Anwendung und öffnen Sie die EAP-Datei. Diese Datei enthält die Profildefinition 

sowie die Definitionen für den Diagrammtypen und die EA-Toolbox. 

3. Modellieren Sie Ihre Erweiterung. Nun können Sie Änderungen am Profil oder den 

Diagramm- und Toolbox-Definitionen vornehmen oder weitere Profile hinzufügen. 

Hinweise zur Erweiterung von MDG-Technologien und zum Umgang mit Enterprise 

Architect können aus [Sparx09] und [Sparx10] entnommen werden. 


7 Zusammenfassung 

In diesem Ergebnisdokument wurde das integrierte Gesamtprofil für das modellbasierte 

Requirements Engineering im Requirements View der SPES-Methode, basierend 

auf dem initialen RE-Ansatz und den darauf aufbauenden Erweiterungen beschrieben´. 

Es fasst die bisher erstellten drei Einzelprofile zusammen und erweitert 

sie. Dazu wurde zunächst der Stand der Wissenschaft im modellbasierten Requirements 

Engineering und in der Erstellung domänenspezifischer Modellierungssprachen 

zusammengefasst, sowie ein Überblick gegeben über die Anforderungen der 

Industriepartner an einen Ansatz für die durchgehend modellbasierte Entwicklung, 

die sich aus der Ausarbeitung zweier Fallstudien ergaben. In den Fallstudien wurde 

festgestellt, dass methodische Anleitung und insbesondere auch Werkzeugunterstützung 

für den Requirements View notwendig ist. 

Im Requirements View wurde bereits die Grundlage für eine Werkzeugunterstützung 

gelegt, die ein durchgängig modellbasiertes Requirements Engineering für Embedded 

Systems erleichtern soll. Die dort enthaltenen Modelle umfassen die Zielmodellierung 

per KAOS-Modell als Grundlage für die systematische Erhebung und Verfeinerung 

von Anforderungen, die Szenariomodellierung durch Use-Cases und Sequenzdiagramme 

zur Erhebung und Verfeinerung von Anforderungen auf mehreren 

Abstraktionsebenen und zur Konkretisierung von Zielen, sowie lösungsorientierten 

Anforderungen zur strukturierten Modellierung der durch Ziele und Szenarien erhobenen 

Anforderungen. 

Diese Modelle wurden einzeln bereits in den drei vorigen Teilergebnissen 

[SPES11b], [SPES11c], [SPES11d] für den Enterprise Architect implementiert. In 

diesem Dokument wurden die im initialen Ansatz verwendeten Modelle kurz zusammengefasst. 

Ferner wurden die Erweiterungen des Gesamtprofiles gegenüber dem 

initialen Ansatzes beschrieben. Es wurde ein Gesamtprofil des Requirements Views 

als SysML-Profil für Enterprise Architect implementiert, welches die in den einzelnen 

Teilergebnissen beschriebenen Teilprofile integriert. Darüber hinaus wurden die vorgeschlagenen 

Erweiterungen um die expliziten Perspektiven Umwelt und Architekturüberblick 

mit Modellelementen des Datenmodells/internen Blockdiagramms der 

SysML implementiert. Mit dem in diesem Dokument beschriebenen einheitlichen EA- 

Profil soll die werkzeugbasierte Unterstützung für die prototypische Verwendung des 

initialen modellbasierten RE-Ansatzes realisiert werden. Weitere Arbeiten umfassen 

das Bereitstellen einer auf diesem Gesamtprofil aufbauenden vollständigen Werkzeugunterstützung. 


8 Referenzen 

[Davis93] Davis, A. M.: Software Requirements – Objects, Functions, and 

States. 2 nd Edition. Prentice Hall, 1993. 

[KeTo08] Kelly, Steven; Tolvanen, Juha-Pekka; Domain-specific Modeling 

– Enabling Full Code Generation. John Wiley & Sons, Inc., Hobo-ken, 

Ney Jersey, 2008. 

[LETA08] Lagarde, François; Espinoza, Huáscar; Terrier, François; André, 

Charles; Gérard, Sébastien; Leveraging Patterns on Domain 

Models to Improve UML Profile Definition. Fundamental Approaches 

to Software Engineering; Lecture Notes in Computer 

Science, SpringerLink, Volume 4961/2008, S. 116-130. 2008. 

[OMG10a] Object Management Group. OMG Systems Modeling Language 

(OMG SysML) Language Specification v1.2. OMG Document 

Number: formal/2010-06-02. 2010. 

[OMG10b] Object Management Group: UML Superstructure Version 2.3, 

OMG formal/10-05-05 http://www.omg.org/spec/UML/2.3/ (2010) 

[OMG11a] Object Management Group. OMG Meta Object Facility (MOF) 

Core Specification v2.4 – Beta 2. OMG Document Number: 

dtc/2010-12-08. 2011. 

[Pohl10] Pohl, Klaus. Requirements Engineering – Foundations, Principles, 

Techniques. Springer, 2010. 

[SiPo10] Sikora, Ernst; Pohl, Klaus. Evaluation eines modellbasierten Requirements-Engineering-Ansatzes 

für den Einsatz in der Motorsteuerungs-Domäne. 

Proceedings of ENVISION2020 2010. 

[RespIT07] Respect-IT. A KAOS Tutorial v1.0. (2007) 

[Sparx09] SparxSystems. Enterprise Architect User Guide. 2009. 

[Sparx10] SparxSystems. Enterprise Architect Software Developers’ Kit. 

2010. 

[SPES09a] Lauenroth, Kim; Sikora, Ernst; Stallbaum, Heiko; Tenbergen, Bastian. 

Initialer modellbasierter Requirements Engineering Ansatz für 

Embedded Systems. SPES 2020 Teilergebnis, Version 0.92 vom 

13.11.2009. 

[SPES10a] Lauenroth, Kim; Gabrisch, Sebastian; Sikora, Ernst; Tenbergen, 

Bastian. Beschreibung der Durchführung der Studie zum Stand 

der Praxis im Requirements Engineering für Embedded Systems. 

SPES 2020 Teilergebnis, Version 1.0 vom 16.07.2010. 

[SPES10b] Daun, Marian; Sikora, Ernst; Lauenroth, Kim. Stand der Praxis im 

modellbasierten Requirements Engineering. SPES 2020 Deliverable 

D2.1.A, 2010. 

[SPES11a] Avramova, Nadezhda; Tenbergen, Bastian. Untersuchung des 

State-of-the-Art zur Erstellung von Domänenspezifischen Modellierungssprachen 

und UML/SysML-Profilen. SPES 2020 Teilergebnis 

des ZP-AP2, Version 1.0 

[SPES11b] Tenbergen, Bastian; Daun, Marian. UML/SysML-Profil und MDG- 


Plug-In für Enterprise Architect zur Modellierung von KAOS- 

Zieldiagrammen auf Basis von UML/SysML. Version 1.2 vom 

13.10.2010 

[SPES11c] Avramova, Nadezhda; Daun, Marian; Tenbergen, Bastian; Weyer, 

Thorsten. SysML-Profil und MDG-Plug-In für Enterprise Architect 

zur Szenariomodellierung auf Basis von SysML. SPES 2020 Teilergebnis 

des ZP-AP2, Version 1.0 vom 02.03.2011 

[SPES11d] Daun, Marian; Gabrisch, Sebastian; Tenbergen, Bastian; Weyer, 

Thorsten. SysML-Profil und MDG-Plug-In für Enterprise Architect 

zur Modellierung von lösungsorientierten Anforderungen auf Basis 

von SysML. SPES 2020 Teilergebnis des ZP-AP2, Version 1.1 

vom 12.04.2011 

[SPES11e] Tenbergen, Bastian; Daun, Marian; Bohn, Philipp. Leitfaden und 

Projektschablonenbeschreibung für die modellbasierte Dokumentation 

von Anforderungen und Entwurf für Embedded Systems 

über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen 

Modellierungswerkzeugs. SPES Deliverable D2.4B, Version 

1.0 vom 29.04.2010. 

[SPES11f] Eder, Sebastian; Vogelsang, Andreas; Feilkas, Martin; Gezgin, 

Tayfun; Daun, Marian; Tenbergen, Bastian; Weyer, Thorsten. 

Seamless Modeling of an automation example using the SPES 

methodology. SPES Teilergebnis, Draft Version 0.3 vom 

27.05.2011. 

[STP11] Sikora, Ernst; Tenbergen, Bastian; Pohl, Klaus. Requirements Engineering 

– An Investigation of Industry Needs. Proceedings of 

Requirements Engineering: Foundations for Software Quality 

REFSQ 2011. 

[VaLa09] Van Lamsweerde, A.: Requirements Engineering – From System 

Goals to UML Models to Software Specifications. Wiley, 2009 


Anhang A – Untersuchung des State-of-the-Art zur Erstellungen 

von domänenspezifischen Modellierungssprachen 

und UML/SysML-Profilen

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen 

Modellierungssprachen und UML/SysML-Profilen 


Verantwortlich Bastian Tenbergen 

QS-Verantwortlich Raphael Weber (OFFIS) 



Version: 1.0 



X Öffentlich 


vorgelegt 

X fertig gestellt


Erzeugung Nadezhda Avramova (NA), Bastian Tenbergen (BT) 

Mitwirkend Marian Daun (MD), Thorsten Weyer (TW) 


Änderung 


Geänderte 

Kapitel 


1 13.12.10 0.1 Alle Initiale Produkterstellung NA In Bearbeitung 

2 21.12.10 - - Internes Review BT In Bearbeitung 

3 14.01.10 0.3 2, 3, 4 Inhaltliche Vervollständigung NA In Bearbeitung 

4 19.01.11 0.4 3, 4, 5 Inhaltliche Überarbeitung BT In Bearbeitung 

5 20.01.11 0.5 1, 3, 4, 5 Inhaltliche Überarbeitung BT In Bearbeitung 

6 25.01.11 0.6 Alle Vervollständigung BT In Bearbeitung 

7 03.02.11 - - Externes Review OFFIS Vorgelegt 

8 09.02.11 1.0 Alle Überarbeitung nach Review BT Fertig gestellt

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen 

und UML/SysML-Profilen 

Kurzfassung 

Die Vorarbeiten der Universität Duisburg-Essen (siehe [DaSiLa10], [LaGaSiTe10] 

und [SiTePo11]) haben gezeigt, dass für die industriereife Verwendung des initialen, 

modellbasierten Requirements-Engineering-Ansatzes [LaSiStTe09] eine Werkzeugunterstützung 

fehlt. Die Erhebung zum Stand der Praxis des modellbasierten Requirements 

Engineering zeigt außerdem, dass insbesondere UML und SysML von der 

Industrie für modellbasierte Entwicklungsaktivitäten häufig Verwendung finden. Anforderungen 

an den einen modellbasierten RE-Ansatz schließen unter anderem die 

Verwendung methodenspezifischer Modellierungssprachen ein. UML-Profile 

[FuVa04] stellen einen Mechanismus bereit, das UML-Metamodell Meta-Object Facility 

(MOF, [OMG06]) domänenspezifisch zu Erweitern. Um eine methodenspezifische 

Erweiterung der MOF in Bezug auf einen neuen modellbasierten Ansatz erstellen zu 

können wurde daher zunächst der Stand der Praxis zur domänenspezifischen Erweiterung 

untersucht. Dieses Dokument fasst die Ergebnisse der Untersuchung zusammen. 




Inhalt 

1 Einordnung und Kurzbeschreibung ..................................................................... 5 

1.1 Motivation und Einordnung ............................................................................ 5 

1.2 Management Summary ................................................................................. 5 

1.3 Überblick ....................................................................................................... 5 

2 Unterscheidung von DSML und UML/SysML-Profilen ......................................... 6 

3 Methoden zur systematischen Erstellung von DSMLs ........................................ 7 

3.1 Methode nach Kelly und Tolvanen ................................................................ 7 

3.2 Methode nach Alanen und Porres ................................................................. 9 

3.3 Fazit zur Erstellung von DSMLs .................................................................. 10 

4 Methoden zur Systematischen Erstellung von Profilen...................................... 11 

4.1 Ad-Hoc Methode.......................................................................................... 11 

4.2 Methode nach Lagarde et al. ....................................................................... 11 

4.3 Methode nach Selic ..................................................................................... 12 

4.4 Fazit zur UML-Profilerstellung ..................................................................... 13 

5 Beispiele für DSMLs und UML/SysML-Profile ................................................... 14 

5.1 Beispiele für Domänenspezifische Modellierungssprachen ......................... 14 

5.2 Beispiele für UML-Profile ............................................................................. 15 

6 Zusammenfassung ............................................................................................ 17 

7 Literaturverzeichnis ........................................................................................... 18 






Das vorliegende Ergebnisdukument beschreibt den Stand der Wissenschaft zum 

Thema „Erstellung von Domänenspezifischen Sprachen und UML/SysML-Profilen“. 

Es liefert die Ausgangsbasis für die Methodenauswahl, nach der Profilunterstützung 

für den initialen, modellbasierten Requirements-Engineering-Ansatz implementiert 

werden soll. 


Die Vorarbeiten der Universität Duisburg-Essen (siehe [DaSiLa10], [LaGaSiTe10] 

und [SiTePo11]) haben gezeigt, dass für die industriereife Verwendung des initialen, 

modellbasierten Requirements-Engineering-Ansatzes [LaSiStTe09] eine Werkzeugunterstützung 

fehlt. Die Erhebung zum Stand der Praxis des modellbasierten Requirements 

Engineering zeigt außerdem, dass insbesondere UML und SysML von der 

Industrie für modellbasierte Entwicklungsaktivitäten häufig Verwendung finden. Anforderungen 

an den einen modellbasierten RE-Ansatz schließen unter anderem die 

Verwendung methodenspezifischer Modellierungssprachen ein. UML-Profile 

[FuVa04] stellen einen Mechanismus bereit, das UML-Metamodell Meta-Object Facility 

(MOF, [OMG06]) domänenspezifisch zu erweitern. Um eine methodenspezifische 

Erweiterung der MOF in Bezug auf einen neuen modellbasierten Ansatz erstellen zu 

können wurde daher zunächst der Stand der Praxis zur domänenspezifischen Erweiterung 

untersucht. Dieses Dokument fasst die Ergebnisse der Untersuchung zusammen. 


Im folgenden Abschnitt wird eine Unterscheidung zwischen domänenspezifischen 

Modellierungssprachen und UML/SysML-Profilen getroffen. Abschnitt 3 befasst sich 

mit Methoden zur strukturierten Erstellung von domänenspezifischen Sprachen und 

Abschnitt 4 behandelt die systematische Definition von UML/SysML-Profilen. Abschnitt 

5 gibt einige Beispiele für Sprachen, die nach den Methoden in den Abschnitten 

3 und 4 erstellt worden sind. Abschnitt 6 fasst dieses Dokument kurz zusammen. 




2 Unterscheidung von DSML und UML/SysML-Profilen 

In der gängigen Literatur wird prinzipiell zwischen domänenspezifischen Modellierungssprachen 

(Domain-specific modelling languages, DSML) und domänenspezifischen 

Profilen für UML bzw. SysML unterschieden. Kelly und Torvanen [KeTo08] 

betrachten DSMLs hauptsächlich als neuartige und ausschließlich in der gegebenen 

Domäne relevante Modellierungssprachen. Nach ihrer Auffassung sind DSMLs stets 

vollständig neu zu entwickeln, da eine zweckorientierte Neuentwicklung einer DSML 

einer Definition von Metamodell-Erweiterungen bezüglich ihrer Aussagekraft überlegen 

sind. 

Dem gegenüber steht die Auffassung von beispielsweise Lagarde et al. oder Selic 

(siehe [LETG07] oder [Seli07]). Die Autoren betrachten UML/SysML Profile ebenfalls 

als einen adäquate Mechanismus um domänenspezifische Sprachen zu definieren. 

Sie begründen diese Aussage damit, dass eine Erweiterung eines existierenden Metamodells 

(wie beispielsweise OMG’s Meta-Object Facility [OMG06]) dazu führt, dass 

existierende Konzepte (wie beispielsweise Vererbungshierarchien oder Allokation 

von Artefakten aus anderen Modellen) wiederverwendet werden können. Somit kann 

eine domänenspezifische Anpassung spezifisch auf semantische Abbildung der Domäne 

reduziert werden, ohne dass zusätzliche Arbeit für die Definition von Konzepten 

wie Vererbung aufgewendet werden muss. 

Im Folgenden werden diese beiden Auffassungen separat voneinander betrachtet, 

da die Ansätze zu deren Erstellung grundsätzlich unterschiedlich ist. Im nachstehenden 

Abschnitt werden zuerst Methoden zur Erstellung von nicht-MOF-basierten 

DSMLs beschrieben. Im Anschluss werden Methoden zur Erstellung von 

UML/SysML-Profilen erläutert. Jeweils ein Fazit zu den Methoden zur Erstellung von 

DSMLs und von UML/SysML-Profilen wird deren Vor- und Nachteile präsentieren. Im 

Anschluss an diese Arbeit werden Beispiele für nicht-MOF-basierte DSMLs sowie 

UML/SysML-Profile gegeben. 




3 Methoden zur systematischen Erstellung von DSMLs 

Domänenspezifische Modellierungssprachen sind Sprachen, die die Sachverhalte in 

einer gegebenen Domäne so exakt wie möglich abbilden sollen. Eine Domäne kann 

nach [KeTo08] eine Organisation darstellen, oder ein Bereich wie Netzwerke oder 

eingebettete Systeme. Typisch für eine DSML ist, dass sie die erkannten Konzepte 

der Domäne abbildet (z.B. Hardware-Plattform oder Software-Komponenten der Domäne 

„Eingebettete Systeme“) und die Beziehungen zwischen ihnen (z.B. eine 

Hardware-Plattform kann mehrere Software-Komponenten verwalten). Da Domänen 

Gebiete von speziellem Wissen sind, muss auch die entsprechende Modellierungssprache 

dieses spezielle Wissen abbilden. Deshalb müssen laut [KeTo08] DSMLs 

von Experten der Domäne entwickelt werden, die diese Domäne sehr gut kennen 

und die wissen, welche Sachverhalte dort relevant sind, bzw. wie diese Sachverhalte 

in Zusammenhang stehen. Wenn eine DSML von Experten entwickelt und qualitätsgesichert 

ist, wird sie zur Modellierung durch die Entwickler in der Domäne verwendet. 

Die DSML soll dabei die Arbeit der Entwickler wesentlich erleichtern, da die Entwickler 

die Domänenbestandteile gut kennen und diese einfach durch die Modellierungssprache 

in den gewünschten Modell ausdrücken sollen. 

DSMLs stellen zum großen Teil auch „Best Practices“ der betrachteten Domäne dar. 

Best Practices kann die Art und Weise sein, wie Modelle in dieser Domäne erstellt 

werden, aber auch erkannte Muster in den Domänenmodellen und in den Assoziationen 

zwischen Modellelementen und dazugehörigem Code bei der späteren Phasen 

des Softwareentwicklungsprozesses. Daher stellen die DSMLs oft eine Grundlage 

zur modellgetriebenen Softwareentwicklung dar, wobei vollständiger und lauffähiger 

Systemcode direkt aus den Domänenmodellen generiert werden kann. 

3.1 Methode nach Kelly und Tolvanen 

Die Methode zur Entwicklung einer DSML nach [KeTo08] ist ein fünfschrittiger Prozess. 

Im Folgenden werden die Schritte in der Methode benannt und kurz erläutert. 

3.1.1 Identifizieren der Domänenkonzepte und Abbilden in die DSML 

In diesem Schritt muss der Entwickler der Sprache die Domäne genau untersuchen 

und die wesentlichen Konzepte der Domäne identifizieren, beispielsweise mit Hilfe 

von Interviews oder sonstigen Gewinnungstechniken (eine Auswahl potentiell anwendbarer 

Methoden kann in [Pohl10] nachgelesen werden). Die Domänenkonzepte 

verstecken sich meistens in den Begriffen, die die Mitarbeiter der Domäne verwenden 

(die Fachsprache), in der Art und Weise wie sie Modelle erstellen und Software- 

Produkte entwickeln, aber auch in den bereits entwickelten Architekturen und Code 

von früheren Projekten (besonders bei eingebetteten Systemen). Oft existiert in einer 

Domäne eine Fachsprache, welche Begriffe enthält, die von allen Beteiligten gleich 

interpretiert werden und für Domänenexterne unbekannt sind. Die Art und Weise der 

Entwicklung eines Softwaresystems verraten dem Entwickler der neuen DSML ähnliche 

Modellierungs- oder Implementierungsmuster, die er/sie ebenso durch die DSML 

widerspiegeln kann. Den auf diese Weise erkannten Domänenkonzepten ordnet der 




Entwickler Modellierungskonzepte zu. Auf diese Weise wird sichergestellt, dass die 

für den Zweck der DSML wichtigen Domänenkonzepte zu den Hauptmodellierungselementen 

der neuen Sprache werden. 

3.1.2 Formalisieren eines Metamodells 

In diesem Schritt formalisiert der Entwickler die neu entwickelte Modellierungssprache 

durch die Erstellung eines Metamodells. In einem Metamodell werden die zugelassenen 

Modellierungselemente formal beschrieben, sowie Regeln festgelegt, wie 

sie miteinander im Modell kombiniert werden dürfen. Das Metamodell kann auch als 

Grundlage für CASE-Werkzeuge dienen, sodass mit Hilfe des Metamodells durch 

das CASE-Werkzeug ein Modellierungswerkzeug generiert werden kann (ähnlich 

dem GMF-Framework von Eclipse). Die Erstellung eines konkreten Modells in der 

neuen DSML auf Basis des Metamodells der DSML entspricht einer Instanziierung 

des Metamodells. 

3.1.3 Definieren der Semantik 

Im dritten Schritt muss der Bezug zwischen den Konzepten der Domäne und den 

Modellierungselementen hergestellt werden. Die Semantik beschreibt, was die Modellierungselemente 

der DSML ausdrücken, also welche Konzepte der Domäne sie 

abbilden. Meistens ist die Semantik bekannt schon vor der Entwicklung der DSML, 

da alle Domäneninternen dasselbe unter einem Begriff verstehen. Diese Semantik 

wird einfach der domänenspezifischen Modellierungssprache hinzugefügt. 

3.1.4 Definieren der graphischen Notation 

Nach der Auffassung von Kelly und Tolvanen ist die graphische Notation der neuen 

DSML zwar nicht von primärer Wichtigkeit bei der Erstellung einer DSML (im Gegensatz 

zu der Anwendung der DSML, bei der die graphische Notation eine entscheidende 

Rolle spielt). Allerdings kann die graphische Notation die Einarbeitung in die 

Sprache von den Domänenentwicklern deutlich erleichtern. Im vierten Schritt soll auf 

Basis der bisherigen Arbeitsschritte die graphische Notation entwickelt werden. Das 

geschieht, indem für jedes in Schritt 1 (siehe Abschnitt 3.1.1) identifizierte Modellierungselement 

ein passendes Symbol gewählt wird. Es ist von Vorteil, eine Notation 

zu wählen, die in den früher erstellten Modellen gerne benutzt worden ist, da so auf 

Vorwissen der Entwickler zurückgegriffen werden kann. 

3.1.5 Validieren und weitergehende Pflege 

An letzter Stelle bei der Entwicklung einer DSML muss diese von den anderen Domänenentwicklern 

auf Konsistenz zur abgebildeten Domäne überprüft werden. Dies 

erfolgt anhand von (teilweise domänenspezifischen) Kriterien, beispielsweise wie 

hoch der Einarbeitungsaufwand ist, wie gut die Anwendbarkeit der Sprache ist oder 

ob die Domänenkonzepte korrekt abgebildet werden. Zum Erstellungsprozess einer 

DSML gehört auch die Pflege der Sprache. Die Domäne kann sich im Laufe der Zeit 

ändern und die Sprache muss diese Änderungen entsprechend umsetzen können. 




Neue Modellelemente können nach Bedarf definiert werden oder veraltete/unbenutzte 

herausgenommen werden. 

3.2 Methode nach Alanen und Porres 

Alanen und Porres schlagen in [AlPo08] eine Methode zur Entwicklung von domänenspezifischen 

Modellierungssprachen durch Erweiterung eines bestehenden Metamodells 

vor. In ihrem Beispiel in [AlPo08] verwenden die Autoren als bestehendes 

Metamodell das UML/SysML-Metamodell MOF (Meta Object Facility, [OMG06]), das 

hauptsächlich nach dem Prinzip der Spezialisierung, bekannt aus objektorientierten 

Programmierungssprachen, aufgebaut ist. Dabei ist zu beachten, dass diese Form 

der Erweiterung von Metamodellen (sogenannte Heavyweight Extension) nicht zu 

einem UML/SysML-Profil führt, sondern vielmehr zu einer MOF-basierten DSML, die 

orthogonal zur UML ist. 

Alanen und Porres zeigen, dass der Ansatz sich auch allgemein für die Entwicklung 

domänenspezifischen Modellierungssprachen eignet. In diesem Ansatz existiert ein 

Metamodell mit Modellelementen, die auf einer sehr hohen Abstraktionsebene spezifiziert 

sind, und enthält z.B. Konzepte wie „Namespace“, „OwnedElement“, etc. Durch 

Spezialisierung dieser generischen Metamodellelemente kann man das Metamodell 

eines erwünschten Modells herausarbeiten. 

Abbildung 1. Heavyweight Metamodell Extension nach Alanen und Porres [AlPo08]. 

Abbildung 1 schematisiert die Erweiterung eines bestehenden Metamodells beispielhaft. 

Es wird gezeigt, wie die Metamodellelemente, die in einem UML- 

Klassendiagramm dargestellt sind, die bereits bestehenden generischeren Metamodellkonzepte 

„Namespace“ und „Element“ durch eine Spezialisierung erweitern. Die 

Packages „Core“ und „Class“, die die beiden Metamodelle umranden, dienen der 

besseren Organisation und logischen Trennung der Metamodelle. Bei einer Spezialisierung 

„erbt“ das Unterelement (z.B. das Element „Class“ in Abbildung 1) alle Eigenschaften 

des Oberelements (z.B. das Element „Namespace“ in Abbildung 1) und 

fügt neue hinzu. Die Spezialisierung von dem Metaelement „Element“ ist aufgeteilt in 




zwei Metaelemente – „Attribute“ und „Operation“. Diese stellen Teileigenschaften des 

generischen Metaelements dar. Die Spezialisierung eines generischen Metamodellelements 

durch Metaelemente, die nur ein Teil seiner Eigenschaften repräsentieren, 

nennen [AlPo08] subsetting. Die Beziehungen zwischen den spezielleren Metamodellkonzepten 

(im Beispiel die Metamodellelementen „Class“, „Attribute“ und 

„Operation“) können anders sein, als zwischen ihren entsprechenden Obertypen. 

Die Autoren sehen den größten Vorteil dieses Ansatzes in der leichten Erweiterung 

einer domänenspezifischen Modellierungssprache. Dann würde der Entwickler die 

Metamodellelementen, der neuen Modellkonzepte als Spezialisierungen eines oder 

mehreren bereits bestehenden Metamodellelemente eingeben. Durch die Vererbung 

werden den neuen Modellelementen alle nötigen Eigenschaften weitergegeben. Der 

Spezialisierungsmechanismus erleichtert zusätzlich den Modelltransformationsprozess, 

der in Werkzeugen durch Codegeneratoren durchgeführt wird. Wenn das Modell, 

das zu transformieren ist, geändert wird, brauchen die Entwickler den Codegenerator 

nicht anzupassen, da die neuen Modellelementen von bereits spezifizierten 

erben und dadurch substituierbar sind. 

3.3 Fazit zur Erstellung von DSMLs 

Domänenspezifischen Sprachen, die konkret für eine Domäne entwickelt worden 

sind, erfassen zum größten Teil „Best-Practices“ dieser Domäne und systematisieren 

damit die typische Art und Weise, wie in dieser Domäne Modellartefakte entwickelt 

werden. Der größte Vorteil einer speziell für eine Domäne erzeugten DSML besteht 

in dem hohen Grad, zu dem diese Modellierungssprache die Sachverhalte in der 

Domäne abbilden kann. Unter ihren Nachteilen ist der (manchmal hohe) Einarbeitungsaufwand, 

der zu der Einführung der neuen DSML, von den Mitarbeitern der 

Domäne gebraucht wird. Auch Werkzeugunterstützung für die neue DSML soll von 

den Domänenexperten selbstständig entwickelt werden und erfordert Zeit und Ressourcen. 

Gängige und kommerzielle Modellierungswerkzeuge können nach der Einführung 

der neuen DSML meistens nicht verwendet werden. 




4 Methoden zur Systematischen Erstellung von Profilen 

In diesem Abschnitt werden Methoden zur Erstellung von UML/SysML-basierten 

DSMLs vorgestellt. Eine Art zum Erstellen einer UML-basierten DSML ist das Konzept 

der „Profile“. Der in UML definierte Profilmechanismus wird von SysML weiterverwendet, 

sodass Profile für beide Sprachfamilien erstellt werden können. SysML- 

Profile sind folglich auch UML-Profile, jedoch nicht umgekehrt. 

UML-Profile sind domänenspezifische Erweiterungen von bestehenden UML- 

Metamodellelementen. Das Basiskonzept von UML-Profilen heißt Stereotype, dazu 

kommen seine Eigenschaften, genannt Tagged Values und zusätzliche Einschränkungen 

des UML-Profils, sogenannte Constraints, welche mit der Object Constraint 

Language (OCL) ausgedrückt werden. 

Allgemein über die Erstellung von UML-Profilen gilt, dass die Konzepte einer Domäne 

u. A. auch spezifischen Eigenschaften der UML Sprache berücksichtigen sollen, 

wie Aufbau und Struktur und vorhandene Modellelemente. Im Weiteren werden einige 

Methoden betrachtet, die von Ad-Hoc Ansatz bis hin zur systematischen Erstellung 

von UML-Profilen gehen. 

4.1 Ad-Hoc Methode 

Lagarde et al. beschreiben in [LETG07] eine Methode zur Erstellung von UMLbasierten 

DSMLs, die sie als Ad-Hoc-Methode bezeichnen. Die Ad-Hoc Methode besteht 

aus einem Schritt, in welchem alle augenscheinlich wichtigen Konzepte der 

Domäne als Stereotypes spezifiziert. Ob alle Sachverhalte einer Domäne abgedeckt 

werden oder ob die Konzepte die richtigen UML-Metamodellelemente erweitern, ist 

durch diese Methode nicht gesichert. 

4.2 Methode nach Lagarde et al. 

In [LETG07] stellen Lagarde et al. eine systematische Methode vor, die die Probleme 

der Ad-Hoc Methode zu lösen vermag. Dabei handelt es sich um einen Ansatz, der 

als Lightweight Extension bezeichnet wird. Im Folgenden sind die drei Schritte dieses 

Ansatzes beschrieben. 

4.2.1 Erstellen eines Domänenkonzeptmodells 

In diesem Schritt wird ein Domänenmodell erstellt, welches die wesentlichen Konzepte 

der Domäne abbildet und in Zusammenhang setzt. Das Domänenkonzeptmodell 

soll alle Konzepte der Domäne enthalten, die die Entwickler für relevant betrachten 

(ähnlich dem Metamodell von Kelly und Tolvanen, [KeTo08]). Bei der Erstellung 

des Domänenkonzeptmodells soll eine Analyse der Domäne stattfinden, die die wesentlichen 

Domänenkonzepte hervorbringen soll. 




4.2.2 Erstellen des Profil-Grundgerüstes 

Das erstellte Domänenkonzeptmodell dient im zweiten Schritt zur Erstellung des 

Grundgerüstes des UML-Profils. Dabei werden die modellierten Konzepte UML- 

Metamodellelementen zugeordnet, indem die Domänenkonzepte aus dem Domänenkonzeptmodell 

zu Stereotypes umgewandelt werden. Alle Beziehungen zwischen 

ihnen bleiben dabei erhalten. Welches Konzept welchem UML-Metamodellelement 

zugeordnet wird, entscheiden die Entwickler des UML-Profils selbst. Die Autoren des 

Ansatzes bieten dazu keine Regeln, da abhängig von der Domäne verschiedene Zuordnungen 

sinnvoll wären. 

4.2.3 Analysieren des Profil-Grundgerüstes 

Im letzten Schritt des Ansatzes wird das Profilskelett analysiert und Inkonsistenzen 

und Widersprüche zum UML-Metamodell werden beseitigt. Die Autoren stellen vier 

mögliche Inkonsistenzen im Grundgerüst vor (sogenannte „Patterns“), die speziell 

analysiert werden müssen: die Verwendung von Kompositionsbeziehungen, Referenzassoziationen, 

Umformulieren von existierenden Konzepten und Erkennung von 

Taxonomien im Grundgerüst. Diese Patterns können zu Inkonsistenzen führen und 

müssen deshalb nach den im Ansatz vorgeschlagenen Strategien aufgelöst werden. 

In [LETA08] geben die Autoren ein ausführliches Beispiel zur Erstellung eines UML- 

Profils nach dem beschriebenen Ansatz und stellen auch dessen Toolunterstützung 

vor. 

4.3 Methode nach Selic 

Bran Selic stellt in [Seli07] ebenfalls einen systematischen Lightweight-Extension- 

Ansatz zur Erstellung von UML-Profilen vor. Dieser Ansatz unterscheidet sich wenig 

von dem in Abschnitt 4.2; es gibt zwei Hauptschritte: Erstellung eines Domänenmodells 

und Zuordnung des Domänenmodells zu UML-Metamodellelementen. 

4.3.1 Erstellen eines Domänenmodells 

Ähnlich dem ersten Schritt in [LETG07] und [LETG08] (siehe Abschnitt 4.2.1) werden 

in diesem Schritt alle Konzepte der Domäne im Domänenmodell erfasst. Selic verdeutlicht 

die Wichtigkeit der vollständigen Abstrahierung von der UML, so dass die 

Domäne möglichst realistisch durch das Modell abgebildet werden kann. Bei der Erstellung 

des Domänenmodells sollen sowohl die abstrakte und konkrete Syntax, als 

auch die Constraints der Sprache und deren Semantik definiert werden. 

4.3.2 Zuordnung des Domänenmodells zu Metamodellelementen 

Im zweiten Schritt wird das eigentliche Profil erstellt, indem die Konzepte des Domänenmodells 

zu UML-Metamodellelementen zugeordnet werden. Anders als bei 

[LETG07] soll eine Konsistenzprüfung während der Zuordnung stattfinden. Dies beinhaltet 

die Überprüfung der Constraints und wie sie sich auf das zu Grunde liegende 

Metamodellelement auswirken, da sie nach der Zuordnung auch auf den Stereotype 




anzuwenden sind. Darüber hinaus sollen die Beziehungen dieses UML-Metamodells 

nach Widersprüchen überprüft werden und eventuell sollen seine Attribute in den 

Stereotypen verfeinert werden. Selic betont, dass die vielen Widersprüche, die zwischen 

dem UML-Metamodell und dem Domänenmodell existieren können, auf eine 

Inkompatibilität dieser Sprachen deuten und ein UML-Profil zu dem gegeben Domänenmodell 

möglicherweise nicht erstellt werden kann. 

4.4 Fazit zur UML-Profilerstellung 

Die UML-Profile stellen einen weiteren Mechanismus zur Spezifizierung einer domänenspezifischen 

Modellierungssprache dar. Ihre Erstellung kann unter Umständen 

mit mehr Aufwand verbunden sein, da die systematische Entwicklung eines UML- 

Profils zuerst die Spezifizierung der Domäne in einem Metamodell einschließt und 

dann seine Zuordnung zum Metamodell. Vorteilhaft bei der Verwendung von UML - 

Profilen ist, dass sie eine Kompatibilität mit UML sicherstellen, so dass auch die Toolunterstützung 

für sie leichter wäre. Darüber hinaus wird der Lernaufwand für die Erlernung 

der neuen Sprache reduziert, wenn Anwender vorher mit UML bzw. SysML 

vertraut gewesen sind. Nachteile der UML-Profile sind dann gegeben, wenn die Konzepte 

der Domäne sich nicht exakt den vorliegenden UML-Metamodellelementen 

zuordnen lassen. Dann soll eine Trade-Off-Entscheidung erfolgen, die entweder eine 

entsprechende Anpassung des Domänenkonzeptmodells, oder Verzicht auf die Verwendung 

eines UML-Profils sein kann. 




5 Beispiele für DSMLs und UML/SysML-Profile 

In diesem Abschnitt werden Beispiele für domänenspezifische Sprachen und Profile 

gegeben. Der nächste Abschnitt zeigt einige exemplarische Beispiele für domänenspezifische 

Sprachen, die nach den in Abschnitt 3 beschriebenen Methoden erstellt 

worden sind. In Abschnitt 5.2 werden einige exemplarische UML/SysML-Profile erläutert, 

die für den Einsatz im Bereich eingebetteter Systeme sinnvoll und wichtig 

sind. 

5.1 Beispiele für Domänenspezifische Modellierungssprachen 

5.1.1 Home Automation System 

Kelly und Torvanen stellen in [KeTo08] mehrere Beispiele für DSMLs vor, die in der 

Realität entwickelt und angewendet worden sind. Das Home Automation System ist 

eines dieser Beispiele und ein System, das verschiedene Geräte, wie Heizung, Beleuchtung, 

aber auch die Sicherheitsanlage in einem Haus kontrollieren soll. Das 

Home Automation System ist ein eingebettetes System, in dem Software und Hardware 

eng miteinander interagieren. Das System stellt ein Telefonmodul dar, das per 

Telefon gesteuert werden kann. Das Modul kann sich auch zu einem Server verbinden, 

um die aktuelle Software zu laden oder Log-Files zu schreiben. Wenn sich der 

Benutzer mit dem System per Telefon verbindet, bietet es ihm ein Sprachmenü an 

und erwartet seine Antwort in Form von Tasteneingaben am Telefon. 

Die entwickelte Lösung einer DSML für das Home Automation System beinhaltet 

zwei Metamodelle der DSML. eines für die Darstellung des Sprachmenüs und eines 

zur Beschreibung der Sprachmeldungen vom System. 

Das erste Metamodell stellt eine Beschreibung der Prozesse dar, die bei einem Benutzeranruf 

stattfinden können: „Sprachausgabe“, bei der das System dem Benutzer 

etwas mitteilt und „Tasteneingabe“, die das Warten des System auf eine Eingabe am 

Telefon seitens des Benutzers repräsentiert. Das zweite Metamodell verfeinert Konzepte 

aus dem Ersten; das Konzept „Sprachausgabe“ wird weiter verfeinert, indem 

Mechanismen zum Zusammenstellen von Sätzen aus einzelnen aufgenommenen 

Wörtern dargestellt werden und Fehlertoleranzverfahren gegenüber falschen Benutzereingaben 

spezifiziert werden. Die konkrete Syntax der DSML ähnelt die eines 

Flow Charts, da diese Notation vor der Einführung der DSML in der Domäne üblich 

gewesen ist. Die Modelle, erstellt mit der DSML, sollen zur Kommunikation mit dem 

Benutzer dienen und zur Generierung von Systemcode in Assemblersprache. 

5.1.2 Sinoptic 

In [CBBB10] stellen Cortier et al. eine DSML vor, die für die Modellierung von eingebetteten 

Systemen für Satelliten und Raumschiffen geeignet ist. Diese DSML wurde 

durch eine Heavyweight Extension erstellt (siehe Abschnitt 3.2). Diese Systeme enthalten 

Echtzeit-Software, die entsprechend der Mission im Weltraum, verschiedene 

Dienste leisten. Die DSML soll sowohl die Software- und Hardwarearchitektur, als 




auch die Prozesse, die im System stattfinden, beschreiben können. Die DSML besteht 

daher aus drei Blöcken – Softwarearchitektur, Dynamische Architektur und 

Hardwarearchitektur. Der Softwarearchitekturblock beschreibt die Struktur der Software 

und auch deren Verhalten durch State Charts innerhalb der Software- 

Komponenten. Der Hardwarearchitekturblock dient zur Modellierung der Hardwarekomponenten. 

Der Block der dynamischen Architektur repräsentiert Software- 

Threads mit notierten Echtzeitaspekten, wie Häufigkeit, Priorität, Aktivierungsbedingungen. 

Zwischen allen Blöcken bestehen Zuordnungen, so dass die Modelle aller 

Blöcke konsistent zueinander gehalten werden. Die DSML kann auch zur Generierung 

von Systemcode benutzt werden. 

5.1.3 Domain-specific Modeling of Power Aware Distributed Real-time 

Embedded Systems 

Madl und Dutt entwickeln in [MaDu06] eine DSML zur Modellierung von stromsensitiven 

eingebetteten Systemen mit Echtzeitanforderungen und bedienen sich ebenfalls 

des Heavyweight Extension Mechanismus (siehe Abschnitt 3.2). Die DSML mit dem 

Namen ALDERIS (Analysis Language for Distributed, Embedded and Realtime Systems) 

stellt komplexe Echtzeitaspekte sowie Energiesparmechanismen eines eingebetteten 

Systems dar. Die zentralen Domänenkonzepte sind u. A. Threads, Aufgaben 

und der Prozessor, der die Tasks verarbeitet. Die konkrete Syntax der Sprache 

wird durch Bildersymbole repräsentiert. Aus der DSML wird XML-Code generiert, der 

als Eingabe eines Werkzeugs für Simulationen und Modellverifikation dient. 

5.2 Beispiele für UML-Profile 

5.2.1 UML TUT 

Das TUT-Profil ist ein UML-Profil, vorgestellt von Kukkala et all. [KRHH05], und ist 

speziell zur Modellierung von eingebetteten Systemen gedacht. Da für eingebettete 

Systeme eine enge Beziehung zwischen Software und Hardware typisch ist, besteht 

das TUT-Profil aus drei Konzepten: Anwendungsbeschreibung (Modellierung der 

Softwareanwendung), Plattformbeschreibung (Modellierung der Hardware des Systems) 

und Mapping zwischen diesen beiden Beschreibungen. Die zu Grunde liegenden 

Stereotypen des TUT-Profils erweitern die UML-Metamodellklassen „Class“ oder 

„StructuralFeature“ für die Knotenelemente und „Dependency“ für die Beziehungselemente. 

Tagged-Values der jeweiligen Stereotypen werden zu Parametrisierung 

des Modells verwendet. Nachdem die Modelle der Anwendung und der Plattform erstellt 

worden sind, werden diese durch den Stereotypen „Mapping“ einander zugeordnet. 

Bei dem Mapping werden Gruppen von Prozessen im Anwendungsmodell 

den entsprechenden Plattformkomponenten zugeordnet. 

5.2.2 SystemC 

Das UML-Profil für SystemC von Riccobene et al. (siehe [RSRB05]) ist ein Profil zur 

Modellierung von System-on-a-Chip (SoC) Systemen auf Systemebene. Das Ziel des 

Profils ist es, zur Verbesserung des Designs von SoC Systemen beizutragen. SoC- 




Systeme sind eingebettete Systeme, deren gesamte Komponenten auf einem einzelnen 

Chip aufgebracht sind. Für die Spezifizierung dieser Systeme, erkennen die 

Autoren den Bedarf an Erhöhung des Abstraktionsniveaus der Modellierung bis Systemebene. 

Gleichzeitig ist die Sprache SystemC weit eingesetzt zur Entwicklung von 

SoC-Systemen. Das UML-Profil für SystemC soll die Fähigkeit der SystemC-Sprache 

widerspiegeln, Struktur und Verhalten darzustellen. Aus dem mit Hilfe des Profils erstellten 

UML Modell soll der Systemcode in SystemC generiert werden. Das UML- 

Profil für SystemC beinhaltet Konzepte zu Modellierung von Struktur – Modules und 

Ports, und zu Modellierung von Verhalten – Channels, Threads und Events. Die 

Strukturkonzepte erweitern die UML-Diagramme „Class Diagram“ und „Composite 

Structure Diagram“ und die Verhaltenskonzepte – die UML State Machines. 

5.2.3 UML QoS 

Das UML-Profil “for Modelling Quality of Service and Fault Tolerance Characteristics 

and Mechanisms (QoS)“ ist eines der bekanntesten UML-Profile der Object Management 

Group (OMG) [OMG05]. Es wurde entwickelt zur Darstellung von Qualitätseigenschaften 

in UML-Diagrammen durch Annotationen. Das QoS-Profil besteht aus 

dem zentralen Konzept, genannt QoS Characteristics, die die Qualitätseigenschaften 

eines Systems wiederspiegeln: Performance, Dependability, Security, Integrity, Coherence, 

Throughput, Latency, Efficiency, Demand, Reliability und Availability. Jede 

QoS-Characteristic stellt eine Template-Klasse dar, die Parametern enthält. Den Parametern 

werden im UML-Modell konkrete Werte zugeordnet. Das annotierte UML- 

Model mit QoS-Eigenschaften heißt Quality Model. Darüber hinaus enthält das QoS- 

Profil auch sog. QoS-Constraints, die den Wertebereich des QoS-Characteristics 

einschränken und QoS-Levels, die die Systemzustände (bzgl. verfügbare Ressourcen, 

geforderte Qualität, Systemvariablenbelegung, etc.) repräsentieren. 





In diesem Dokument wurden mehrere Methoden zur Erstellung von domänenspezifischen 

Modellierungssprachen (domain-specific modelling languages, DSML) vorgestellt. 

Dabei muss man den Begriff „domänenspezifische Modellierungssprache“ 

grundsätzlich auf zwei unterschiedliche Weisen auffassen: Domänenspezifische 

Sprachen mit eigenen Metamodellen und domänenspezifische Metamodellerweiterungen 

durch UML/SysML-Profile. Vorgestellt wurden drei prinzipielle Ansätze: Heavyweight 

Extension für Metamodellerstellung ([AlPo08] und [KeTo08]), Lightweight 

Extension durch Metamodellerweiterung ([LETA07], [LETA08] und [Selic07]) und eine 

Ad-hoc-Method ([LETA07]). Des Weiteren wurden verschiedene Profile, die typische 

Erweiterungsansätze umgesetzt haben, vorgestellt. 

Im Projekt SPES 2020 soll für die Unterstützung des initialen, modellbasierten Requirements-Engineering-Ansatzes 

methodenspezifische Modellierungssprachen und 

Werkzeuge entwickelt werden. Die Untersuchung des Standes der Wissenschaft zur 

Ableitung modellbasierter Sprachen und die Vorarbeiten der Uni-DUE (beispw. 

[DaSiLa10] und [SiTePo11]) haben gezeigt, dass eine Unterstützung des initialen 

Ansatzes durch methodenspezifische Profile vollbracht werden können. In weiteren 

Arbeiten werden diese Profile auf Basis der hier vorgestellten Ansätze erstellt. 




7 Literaturverzeichnis 

[AlPo08] Alanen, Marcus; Porres, Ivan; A metamodeling language supporting 

subset and union properties. Software and Systems Modeling, 

SpringerLink, Volume 7, Number 1, S. 103-124. 2008. 

[CBBB10] Cortier, A.; Besnard, L.; Bodeveix, J. P.; Buisson, J.; Dagnat, F.; 

Filali, M.; Garcia, G.; Ouy, J.; Pantel M.; Rugina, A. Synoptic: A 

Domain-Specific Modeling Language for Space On-board Application 

Software. Synthesis of Embedded Software, SpringerLink. S. 

79-119. 2010. 

[DaSiLa10] Daun, Marian; Sikora, Ernst; Lauenroth, Kim. Stand der Praxis im 


D2.1.A, 2010. 

[FuVa04] Fuentes-Fernándes, L.; Vallecillo-Moreno, A.: An Introduction to 

UML Profiles. Upgrade 5(2) (2004). 

[KeTo08] Kelly, Steven; Tolvanen, Juha-Pekka; Domain-specific Modeling – 

Enabling Full Code Generation. John Wiley & Sons, Inc., Hoboken, 

Ney Jersey, 2008. 

[KRHH05] Kukkala, Petri; Riihimäki, Jouni; Hännikäinen, Marko; Hämäläinen, 

Timo D.; Kronlöf, Klaus. UML 2.0 Profile for Embedded System 

Design. Proceedings of the conference on Design, Automation 

and Test (DATE '05) in Europe - Volume 2. 7-11 März, 2005. 

[LaGaSiTe10] Lauenroth, Kim; Gabrisch, Sebastian; Sikora, Ernst; Tenbergen, 




[LaSiStTe09] Lauenroth, Kim; Sikora, Ernst; Stallbaum, Heiko; Tenbergen, Bastian. 



18.09.2009. 

[LETA08] Lagarde, François; Espinoza, Huáscar; Terrier, François; André, 

Charles; Gérard, Sébastien; Leveraging Patterns on Domain 

Models to Improve UML Profile Definition. Fundamental Approaches 

to Software Engineering; Lecture Notes in Computer 

Science, SpringerLink, Volume 4961/2008, S. 116-130. 2008. 

[LETG07] Lagarde, François; Espinoza, Huáscar; Terrier, François; Gérard, 

Sébastien; Improving UML Profile Design Practices by Leveraging 

Conceptual Domain Models. ASE '07 Proceedings of the twentysecond 

IEEE/ACM international conference on Automated soft- 




ware engineering. Atlanta, Georgia, 5-9 Nov. 2007. 

[MaDu06] Madl, Gabor; Dutt, Nikil. Domain-specific Modeling of Power 

Aware Distributed Real-time Embedded Systems. Embedded 

Computer Systems: Architectures, Modeling, and Simulation; Lecture 

Notes in Computer Science, SpringerLink, Volume 

4017/2006, S. 59-68. 2006. 

[OMG05] Object Management Group, UML Profile for Modelling Quality of 

Service and Fault Tolerance Characteristics and Mechanisms, 

OMG Specification, 08-04-05, April 2005. 

[OMG06] Object Management Group: Meta Object Facility Version 2.0, 

OMG Document Number formal/2006-01-01 

http://www.omg.org/spec/MOF/2.0/ (2006) 



[RSRB05] Riccobene, E.; Scandurra, P.; Rosti, A.; Bocchio, S. A SoC Design 

Methodology Involving a UML 2.0 Profile for SystemC. Proceedings 

of the conference on Design, Automation and Test (DATE 

'05) in Europe - Volume 2. 7-11 März, 2005. 

[Seli07] Selic, Bran. A Systematic Approach to Domain-Specific Language 

Design Using UML. ISORC '07 Proceedings of the 10th IEEE International 

Symposium on Object and Component-Oriented Real- 

Time Distributed Computing. Santorini Island. 7-9 Mai, 2007. 

[SiTePo11] Sikora, E.; Tenbergen, B.; Pohl, K.: Requirements Engineering for 

Embedded Systems: - An Investigation of Industry Needs . To appear 

in Proceedings of the 17 th International Working Conference 

on Requirements Engineering: Foundations of Software Quality 

REFSQ (2011) 

[SiStLa10] Sikora, Ernst; Stallbaum, Heiko, Lauenroth, Kim. Anforderungen 

an den zu entwickelnden Ansatz für modellbasiertes Requirements 

Engineering. SPES 2020 Teilergebnis, Version 1.0 vom 

01.03.2010. 


Anhang B – ZP-AP2 Teilergebnis: UML/SysML-Profil und 

MDG-Plug-In für Enterprise Architect zur Modellierung von 

KAOS-Zieldiagrammen auf Basis von UML/SysML

- ZP-AP2 Teilergebnis: UML/SysML-Profil und MDG-Plug-In für Enterprise Architect 

zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML- 


Version: 1.2 

Verantwortlich Bastian Tenbergen (Universität Duisburg-Essen) 

QS-Verantwortlich Tayfun Gezgin (OFFIS e.V.) 





X Öffentlich 


vorgelegt 

X fertig gestellt


Erzeugung Bastian Tenbergen (BT), Marian Daun (MD) 

Mitwirkend Ernst Sikora (ES), Heiko Stallbaum (HS), Tayfun Gezgin (TG) 


Änderung 


Geänderte 

Kapitel 


1 05.09.10 0.1 Alle Initiale Produkterstellung BT In Bearbeitung 

2 07.09.10 Interner Review ES In Bearbeitung 

3 07.09.10 1.0 Alle Editorielle Überarbeitung BT Vorgelegt 

4 30.09.10 Externer Review TG Vorgelegt 

5 05.10.10 1.1 Alle Überarbeitung nach externem 

Review 

BT In Bearbeitung 

6 07.10.10 Interner Review HS In Bearbeitung 

7 13.10.10 1.2 Alle Überarbeitung BT Fertig gestellt

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung 

von KAOS-Zieldiagrammen auf Basis von UML/SysML 

Kurzfassung 

In diesem Dokument wird ein UML/SysML-Profil zur Zielmodellierung auf Basis der 

Systems Modeling Language (SysML) und Unified Modeling Language (UML) vorgestellt. 

Dieses Profil wurde im Rahmen der Ausarbeitung zweier Fallstudien in Kooperation 

mit Bosch und EADS entwickelt und basiert auf den Ausführungen zur Zielmodellierung 

aus dem initialen, modellbasierten Requirements Engineering Ansatz für 

Embedded Systems ([LaSiStTe09]). Die Studie zum Stand der Praxis zum modellbasierten 

Requirements Engineering ([LaGaSiTe10], [DaSiLa10]) hat gezeigt, dass die 

Zielmodellierung derzeit nur eine geringe Rolle im modellbasierten Requirements 

Engineering spielt. Ferner wurde gezeigt, dass durch die systematische Verfeinerung 

von Anforderungen auf mehreren Abstraktionsebenen Vorteile für das Requirements 

Engineering entstehen können. Zielen liegen Anforderungen zu Grunde. Für die systematische 

Erhebung und Verfeinerung von Anforderungen ist es daher unerlässlich, 

zunächst Ziele zu spezifizieren. Im modellbasierten Requirements Engineering werden 

Ziele in Zieldiagrammen ([Pohl10]) modelliert, wie beispielsweise die KAOS- 

Methode es vorsieht ([KAOS07], [Lamsweerde09]). 




Inhalt 




1.3 Überblick ....................................................................................................... 5 

2 Einführung zur KAOS-Zielmodellierung und UML/SysML ................................... 6 

2.1 KAOS-Zielmodellierung ................................................................................. 6 

2.2 UML/SysML ................................................................................................... 6 

2.3 Hinweise zur Implementierung des SysML-Profils mit EA ............................. 7 

3 Beschreibung des MDG-Plug-Ins zur Zielmodellierung nach KAOS in SysML .... 8 

3.1 Überblick über das UML/SysML-Profil ........................................................... 8 

3.2 Elemente der Zielmodelle ............................................................................ 13 

3.3 Beziehungen zwischen den Elementen ....................................................... 14 

3.4 Die Enumerationen „GoalType“ und „ContributionType“ ............................. 15 

4 Verwendung des MDG-Plug-Ins ........................................................................ 16 

4.1 Installation der MDG-Technologie ............................................................... 16 

4.2 Verwendung des Profils ............................................................................... 16 

4.3 Erweiterung des Profils ................................................................................ 18 








Das vorliegende Ergebnisdokument beschreibt das Enterprise Architect Plug-In 

„SysML Goal Modeling“, welches ein UML/SysML-Profil zur Modellierung von Zielen 

nach der KAOS-Methode beinhaltet. Dieses Dokument beschreibt den Aufbau des 

Plug-Ins, gibt eine Beschreibung der Architektur des UML/SysML-Profils und erläutert 

die Verwendung des Profils in Enterprise Architect (EA). 


In diesem Dokument wird ein UML/SysML-Profil zur Zielmodellierung auf Basis der 

Systems Modeling Language (SysML) und Unified Modeling Language (UML) vorgestellt. 

Dieses Profil wurde im Rahmen der Ausarbeitung zweier Fallstudien in Kooperation 

mit Bosch und EADS entwickelt und basiert auf den Ausführungen zur Zielmodellierung 

aus dem initialen, modellbasierten Requirements Engineering Ansatz für 

Embedded Systems ([LaSiStTe09]). Die Studie zum Stand der Praxis zum modellbasierten 

Requirements Engineering ([LaGaSiTe10], [DaSiLa10]) hat gezeigt, dass die 

Zielmodellierung derzeit nur eine geringe Rolle im modellbasierten Requirements 

Engineering spielt. Ferner wurde gezeigt, dass durch die systematische Verfeinerung 

von Anforderungen auf mehreren Abstraktionsebenen Vorteile für das Requirements 

Engineering entstehen können. Zielen liegen Anforderungen zu Grunde. Für die systematische 

Erhebung und Verfeinerung von Anforderungen ist es daher unerlässlich, 

zunächst Ziele zu spezifizieren. Im modellbasierten Requirements Engineering werden 

Ziele in Zieldiagrammen ([Pohl10]) modelliert, wie beispielsweise die KAOS- 

Methode es vorsieht ([KAOS07], [Lamsweerde09]). 


Im folgenden Abschnitt 2 wird eine kurze Einführung zur Zielmodellierung nach der 

KAOS-Methode sowie zu SysML gegeben. In Abschnitt 3 wird das EA-Plug-In 

„SysML Goal Modeling“ erläutert, indem zunächst der Aufbau der zugehörigen EA- 

Projektdatei dargestellt wird (Abschnitt 3.1) und anschließend das UML/SysML-Profil 

anhand seiner Implementierung in Enterprise Architect erläutert wird (Abschnitte 3.2 

bis 3.4). In Abschnitt 4 wird die Installation, Verwendung und Erweiterung des EA- 

Plug-In als MDG-Technologie erläutert. Eine Zusammenfassung dieses Dokumentes 

kann Abschnitt 5 entnommen werden. 




2 Einführung zur KAOS-Zielmodellierung und UML/SysML 

2.1 KAOS-Zielmodellierung 

Ziele beziehen sich auf funktionale Eigenschaften sowie Qualitätseigenschaften, die 

ein System externen Akteuren (Personen und anderen Systemen) bietet. Ziele werden 

auf verschiedenen Abstraktionsstufen definiert und abstrahieren von technischen 

Einzelheiten, Anforderungen sowie von einer möglichen Systemarchitektur. So kann 

beispielsweise die beabsichtigte Nutzung des Systems durch einen externen Akteur 

durch ein Ziel charakterisiert werden. 

Ziele verfeinern die für das System definierte Vision (siehe [Pohl10]). Jedes Ziel leistet 

somit einen Beitrag zur Erfüllung der Systemvision. Gleichzeitig werden Begründungen 

für detaillierte (lösungsorientierte) Anforderungen an das System durch Ziele 

gegeben. 

KAOS ([KAOS07], [Lamsweerde09]) ist eine Modellierungssprache zur Spezifikation 

von Zielen und deren Beziehungen. Durch den Einsatz dieser Modellierungssprache 

ist es im Requirements Engineering möglich, Anforderung anhand von abstrakteren 

Zielen zu begründen und miteinander in Verbindung zu setzen. 

KOAS verfügt über eine Reihe von Modellelementen zur Darstellung von Zielmodellen, 

sowie über eine Menge von definierten Beziehungen zwischen Zielen. Im vorgeschlagenen 

UML/SysML-Profil werden die Modellelemente „Ziel“ (Goal) und „Verfeinerung“ 

(Refinement) betrachtet. Die im Profil betrachteten Beziehungen sind Und- 

Verfeinerungen (And-Refinements) und Oder-Verfeinerungen (Or-Refinements), sowie 

Beteiligungs- oder Konfliktbeziehungen (Contribution- oder Contradiction-links). 

Und-Verfeinerungen spezifizieren, dass alle der Verfeinerung angehörigen Unterziele 

erfüllt sein müssen, damit das Oberziel erfüllt ist. Oder-Verfeinerungen bedeuten, 

dass nur eines der (beliebig vielen) alternativen Unterziele erfüllt sein muss, damit 

das Oberziel erfüllt ist. Beteiligungsbeziehungen geben an, dass die Erfüllung eines 

Zieles die Erfüllung eines anderen Zieles entweder positiv oder negativ beeinflusst, 

also vereinfacht oder beeinträchtigt. Eine Konfliktbeziehung zwischen zwei Zielen 

gibt an, dass die Erfüllung eines Zieles verhindert wird, wenn ein konfliktionäres Ziel 

erfüllt wird. Die Modellierungssprache KAOS spezifiziert außerdem eine Reihe weiterer 

Modellelemente und Beziehungen, wie beispielsweise Verantwortlichkeiten oder 

solche Ziele, die zu vermeiden sind. Diese werde in späteren Revisionen des Zielprofils 

für UML/SysML betrachtet. Zunächst wurden im vorgeschlagenen UML/SysML- 

Profil lediglich jene Elemente der KAOS-Methode berücksichtigt, die zur strukturierten 

Modellierung von Zielen zum Zwecke der Verfeinerung durch Szenarien gemäß 

dem initialen, modellbasierten RE-Ansatz ([LaSiStTe09]) benötigt werden. 

2.2 UML/SysML 

SysML ist eine universelle, graphische Modellierungssprache zur Darstellung und 

Spezifikation von Verhaltens-, Zustands- und Strukturaspekten von Systemen 

([FrMoSt09], [OMG10]). SysML baut auf der Unified Markup Language Version 2.0 

(UML) auf. UML wird durch SysML domänenunabhängig erweitert und erlaubt es, ein 

System lösungsunabhängig zu spezifizieren. Eine Besonderheit der SysML gegenüber 

UML2 ist, dass SysML den Diagramtyp „Requirements Diagram“bietet, mit dem 

es möglich ist, Anforderungen und deren Beziehungen graphisch zu modellieren. 

Allerdings sieht SysML kein Diagramm zur Modellierung von Zielen vor. Das in diesem 

Ergebnisdokument beschriebene Profil für SysML stellt eine Erweiterung von 

UML/SysML zur Modellierung von Zielen nach der KAOS-Methode dar. 




2.3 Hinweise zur Implementierung des SysML-Profils mit EA 

Obwohl SysML Goal Modeling als Profil für SysML zu verstehen ist, muss die Implementierung 

in Enterprise Architect (EA) auf Basis des UML2-Metamodells erfolgen. 

Die Mechanismen, die EA für die Erstellung von Profilen und MDG-Technologien bereit 

hält machen dieses notwendig. So muss ein Stereotyp beispielsweise EAinternen 

Metaklassen wie„Class“ oder „Association“ erben, anstelle von SysMLeigenen 

Metaklassen wie etwa „Block“. Die Erläuterungen in den Abschnitten 3.2 und 

3.3 beziehen sich daher auf die Implementierung des SysML Goal Modeling Profils 

auf Basis des Metamodells von Enterprise Architect. Da das EA-Metamodell auf das 

SysML-Metamodell übertragbar ist, können diese Erläuterungen allerdings als äquivalent 

zu einer Erweiterung des SysML-Metamodells aufgefasst werden. 




3 Beschreibung des MDG-Plug-Ins zur Zielmodellierung 

nach KAOS in SysML 

In diesem Abschnitt wird das Enterprise Architect Plug-In beschrieben, in dem das 

UML/SysML-Profil zur Modellierung von Zielen nach KAOS implementiert wurde. Der 

nächste Unterabschnitt 3.1 gibt einen Überblick über den Inhalt der entsprechenden 

Enterprise Architect (EA) Projektdatei. Im darauffolgenden Unterabschnitt 3.2 werden 

die Modellelemente des UML/SysML-Profils erläutert. In Unterabschnitt 3.3 werden 

die Beziehungen, die zwischen den Modellelementen aus Abschnitt 3.1 existieren, 

erläutert. 

3.1 Überblick über das UML/SysML-Profil 1 

Wie in Abb. 3–1 2 ersichtlich ist, besteht die EA-Projektdatei aus vier SysML-Paketen. 

Diese Pakete werden in den folgenden Abschnitten erläutert. Drei der vier enthaltenen 

Pakete sind mit dem Stereotypen „“ gekennzeichnet. Diese Kennzeichnung 

gibt an, dass es sich bei dem Paket um eine benutzererstellte Erweiterung 

des UML/SysML-Metamodells bzw. des Enterprise Architect Programmumfangs 

handelt. Details und Erläuterungen zur Erweiterung von Enterprise Architect um benutzererstellte 

Profilen können aus [Sparx09] und [Sparx10] entnommen werden. 

Abb. 3–1 SysML-Paketdiagramm des Inhaltes der EA-Projektdatei 

3.1.1 Das Paket „Goal Modeling Elements“ 

Das Paket „Goal Modeling Elements” ist vom Stereotyp „“ und implementiert 

das eigentliche UML/SysML-Profil. In diesem Paket sind alle Modellelemente 

und Beziehungen der KAOS-Methode als Unterklassen von UML2, bzw. SysML- 

1 Pakete, die der Profildefinition dienen, sind in Englisch beschrieben, während Anwendungsbeispiele 

auf Deutsch gehalten sind, um so Profildefinition und Anwendung des Profils deutlicher voneinander 

abzugrenzen. 

2 Alle Diagramme in diesem Dokument sind aus Enterprise Architect von SparxSystems exportiert. 




Elementen definiert.. Abb. 3–2 zeigt den Inhalt dieses Paketes im Detail. Einzelheiten 

zum Inhalt können aus den Abschnitten 3.2 bis 3.4 entnommen werden. 

Abb. 3–2 UML-Klassendiagramm des Inhaltes des Paketes „Goal Modeling Elements“ 

3.1.2 Das Paket „Goal Diagram Definition“ 

Das Paket „Goal Modeling Elements” ist ebenfalls vom Stereotyp „“ und 

implementiert den Diagrammtypen, der zu verwenden ist, wenn in Enterprise Architect 

Zielmodelle erstellt werden sollen. Dieser Diagrammtyp beruft sich auf die Modellelemente 

und Beziehungen aus dem Paket „Goal Modeling Elements“ (siehe Abschnitt 

3.1.1). Das Paket „Goal Diagram Definition“ ist in Abb. 3–3 dargestellt. Wie in 

Abb. 3–3 zu sehen ist, besteht das Paket aus zwei Klassen, einer Klasse „Goal Diagram“ 

und einer Metaklasse „Diagram_Logical“. „Diagram_Logical“ ist eine EAinterne 

Klasse, von der alle strukturellen Diagrammtypen erben. „Goal Diagram“ erbt 

von der Metaklasse „Diagram_Logical“ und spezifiziert somit Zieldiagramme als 

strukturelles Diagramm in Enterprise Architect. In Abb. 3–3 ist zu erkennen, dass 

„Diagram_Logical“ eine Reihe von Attributen spezifiziert, welche die Eigenschaften 




des neuen Diagrammtypen „Goal Diagram“ festlegen. Eine Erläuterung der Attribute 

kann aus [Sparx10] entnommen werden. Besonders hervorzuheben ist das Attribut 

„toolbox“. Dieses Attribut legt die zu verwendende Toolbox im Enterprise Architect 

Editor fest. Die zu verwendende Toolbox ist im Paket „SysML Goal Modeling“ definiert 

und wird in Abschnitt 3.1.3 erläutert. 

Abb. 3–3 UML-Klassendiagramm des Inhaltes des Paketes „Goal Diagram Definition“ 

3.1.3 Das Paket „SysML Goal Modeling“ 

Das Paket „SysML Goal Modeling” ist ebenfalls vom Stereotyp „“ und implementiert 

die für den im Paket „Goal Diagram Definition“ definierten Diagrammtypen 

„Goal Diagram“ (siehe Abschnitt 3.1.2) zu verwendende Toolbox. Die Toolbox ist 

ein Teil des Enterprise Architect Editors, in dem die für den aktuellen Diagrammtypen 

verwendbaren Modellelemente und Beziehungen für die Modellierung zur Verfügung 

gestellt werden. Abb. 3–4 zeigt den Inhalt des Paketes „SysML Goal Modeling“ in 

Form eines UML-Klassendiagrammes.Die Abbildung zeigt zwei Klassen, die beide 

von der EA-internen Metaklasse „ToolboxPage“ erben. Diese Klassen implementieren 

zwei unterschiedliche Sektionen der Toolbox. In einer Sektion „Goal Elements“ 

werden alle Modellelemente (derzeit Ziele und Verfeinerungen) festgelegt, in der anderen 

Sektion „Goal Refinements“, alle Beziehungen zwischen den Modellelementen. 

In den Klassen „Goal Elements“ und „Goal Refinements“ werden Attribute spezifiziert, 

die die zur Verfügung stehenden User-Interface-Elemente (UI-Elemente) festlegen. 

Die UI-Elemente repräsentieren die Modellelemente und Beziehungen aus 

dem Paket „Goal Modeling Elements“ und werden in den Attributen in Paket- 

Notationsform (siehe dazu [Sparx10] und [OMG10] beschrieben. 




Abb. 3–4 UML-Klassendiagramm des Inhaltes des Paketes „SysML Goal Modeling“ 

Die folgende Abb. 3–5 3 zeigt, wie die Toolbox, die durch das Paket „SysML Goal 

Modeling“ definiert wird, im User Interface von Enterprise Architect angezeigt wird. 

Diese Toolbox wird automatisch geöffnet, sobald ein neues Zieldiagram, wie im Paket 

„Goal Diagram Definition“ spezifiziert, erstellt wird. Die Toolbox kann ebenfalls in 

einem beliebigen anderen Diagramm verwendet werden, wenn sie manuell nach einem 

Aufruf von „More tools…“ (siehe Abb. 3–5) aus dem Menü ausgewählt wird. 

Abb. 3–5 Screenshot der Toolbox, wie sie in Enterprise Architect dargestellt wird 

3.1.4 Das Paket „Goal Model Example“ 

Das Paket „Goal Model Example” hat keinen Stereotypen und beinhaltet ein Beispiel 

für die Verwendung der im Paket „Goal Modeling Elements“ spezifizierten Mo- 

3 Alle Screenshots in diesem Dokument zeigen Ausschnitte aus dem Programm „Enterprise Architect“ 

(EA) von SparxSystems. 




dellelemente und Beziehungen. Abb. 3–6 zeigt das Beispiel-Zieldiagramm. Die einzelnen 

Modellelemente und Beziehungen sind in den Abschnitten 3.2 und 3.3 erläutert. 

Besonders hervorzuheben ist die angepasste Darstellung des Diagrammtabs in 

der oberen linken Ecke von Abb. 3–6. Diese besteht aus dem Identifikator „[kaos]“, 

der anzeigt, dass es sich bei dem angezeigten Diagramm um ein Zielmodell nach 

KAOS handelt. Der nachfolgende Name „Goal Model Example“ ist der benutzerdefinierbare 

Name des Diagrammes. Der Text des Diagrammtabs wurde im Paket „Goal 

Diagram Definition“ in der Metaklasse „Diagram_Logical“ unter dem Attribut 

„frameString“ festgelegt. 

Abb. 3–6 KAOS Zieldiagramm aller derzeit implementierten Modellelemente und Beziehungen 

Das Beispiel zeigt zwei Oberziele „hoher Fahrspaß“ und „Sparsam fahren“ vom Typ 

„softgoal“ (siehe Abschnitt 3.2.1.2). Das Ziel „hoher Fahrspaß“ wird von Unterziel 

„schnell fahren“, welches ebenfalls vom Typ „softgoal“ ist, verfeinert. Bei dieser Verfeinerung 

handelt es sich um eine Oder-Verfeinerung, bei der lediglich eine Alternative 

angegeben ist. Das Unterziel „schnell fahren“ muss also erfüllt sein, damit das 

Oberziel „hoher Fahrspaß“ erfüllt ist. Das Oberziel „Sparsam fahren“ wird durch die 

beiden Unterziele vom Typ „hardgoal“ (siehe Abschnitt 3.2.1.1) mit einer Und- 

Verfeinerung verfeinert. Es müssen folglich beide Unterziele „Abgasnorm erfüllen“ 

und „Verbrauch weniger als 6l/100km“ erfüllt sein, damit das Oberziel erfüllt ist. Das 

Unterziel „Verbrauch von weniger als 6l/100km“ steht in einer Beziehung vom Typ 

„Contribution“ (siehe Abschnitt 3.3.4) zum Ziel „Abgasnorm erfüllen“. Diese Beziehung 

bedeutet, dass die Erfüllung des Zieles „Verbrauch weniger als 6l/100km“ sich 

stark positiv auf die Erfüllung des Zieles „Abgasnorm erfüllen“ auswirkt, also die Erfüllung 

des Zieles „Abgasnorm erfüllen“ vereinfacht wird. Das Ziel „schnell fahren“ 

steht ebenfalls in einer Beziehung vom Typ „Contribution“ zum Ziel „Abgasnorm erfüllen“. 

Diese Beziehung besagt, dass die Erfüllung des Zieles „schnell fahren“ die 

Erfüllung des Zieles „Abgasnorm erfüllen“ schwach beeinträchtigt. Des Weiteren 




steht das Ziel „schnell fahren“ im Konflikt mit dem Ziel „Verbrauch weniger als 

6l/100km“, was durch eine Beziehung vom Typ „Contradiction“ (siehe Abschnitt 

3.3.3) dargestellt ist. In diesem Fall verhindert die Erfüllung des Zieles „schnell fahren“ 

die Erfüllung des Zieles „Verbrauch weniger als 6l/100km“. 

3.2 Elemente der Zielmodelle 

In diesem Abschnitt werden die Modellelemente des KAOS-Zielmodells beschrieben, 

die im Paket „Goal Modeling Elements“ definiert wurden. Ein Überblick über das Paket 

kann aus Abschnitt 3.1.1 entnommen werden. Die Erläuterungen in den folgenden 

Abschnitten stützten sich auf Abb. 3–2. Die Verwendung der Modellelemente ist 

in Abb. 3–6 illustriert. 

3.2.1 Die Klasse „Goal“ 

Die Klasse „Goal“ definiert Ziele des Zieldiagrammes und stellt somit das zentrale 

Modellelement im SysML Goal Modeling Profil dar. Ziele erben von der Metaklasse 

„Class“ und werden somit von Enterprise Architect als eigenes Modellelement aufgefasst. 

Die Klasse „Goal“ definiert mehrere EA-interne Attribute, dessen Erläuterung 

aus [Sparx10] entnommen werden können. Besonders hervorzuheben ist dabei das 

Attribut „_image“ und das Attribut „Zieltyp“, welches ein Ziel entweder genauer als ein 

„hardgoal“ (siehe Abschnitt 3.2.1.1.) oder „softgoal“ (siehe Abschnitt 3.2.1.2) definiert. 

Ein generischer Zieltyp „goal“ ist ebenfalls möglich. Dieser generische Typ sagt 

aus, dass eine genauere Klassifizierung des Zieles noch nicht erfolgt ist und ggf. zu 

einem späteren Zeitpunkt festgelegt werden kann. Genauere Informationen zum festlegen 

des Zieltyps können in Abschnitt 3.4 gefunden werden. Das Attribut „_image“ 

definiert das Aussehen des Modellelementes „Goal“ als rechtslastiges Parallelogramm. 

Das Attribut „Zieltyp“ definiert die Art des zu erstellenden Zieles. Die Art des 

Zieles wird in der Enumeration „GoalType“ definiert (vgl. 3.4) und kann entweder 

„goal“, „hardgoal“ oder „softgoal“ sein. Der Zieltyp wird im Stereotypen des Modellelementes 

entsprechend dargestellt. Das Attribut „Zieltyp“ wird im EA-Editor im 

Eigenschaftsfenster des Modellelementes unter dem Registerreiter „Tagged Values“ 

zusammen mit dem Attribut ID dargestellt. Das Attribut ID gibt dem Benutzer die 

Möglichkeit, eine eindeutige ID zu vergeben. 

3.2.1.1 Zieltyp: „hardgoal“ 

Der Zieltyp „hardgoal“ wird durch die Enumeration „GoalType“ definiert. Wenn ein 

Ziel vom Typ „hardgoal“ ist, so wird der Zieltyp im Stereotypen des Ziels dargestellt. 

Ein Ziel vom Typ „hardgoal“ wird als rechtsseitiges Parallelogramm mit durchgezogener 

Linie dargestellt. Die semantische Bedeutung eines Zieles vom Typ „hardgoal“ 

kann aus [KAOS07], [Lamsweerde09] und [Pohl10] entnommen werden. 

3.2.1.2 Zieltyp: „softgoal“ 

Der Zieltyp „softgoal“ wird durch die Enumeration „GoalType“ definiert. Wenn ein Ziel 

vom Typ „softgoal“ ist, so wird der Zieltyp im Stereotypen des Ziels dargestellt. Ein 

Ziel vom Typ „softgoal“ wird als rechtsseitiges Parallelogramm mit gestrichelter Linie 

dargestellt. Die semantische Bedeutung eines Zieles vom Typ „hardgoal“ kann aus 

[KAOS07], [Lamsweerde09] und [Pohl10] entnommen werden. 

3.2.2 Die Klasse „Refinement“ 

Die Klasse „Refinement“ stellt ein Modellelement zur Darstellung von Und- und Oder- 

Verfeinerungen in einem Zieldiagramm dar. Klassen vom Typ „Refinement“ haben 




typischerweise keinen Namen und werden in EA daher generisch mit „Class1“ oder 

„Refinement1“ bezeichnet. Verfeinerungen erben von der Metaklasse „Class“ und 

werden somit von Enterprise Architect als eigenes Modellelement aufgefasst. Verfeinerungen 

werden im EA-Editor als Kreis dargestellt, was durch das Attribut „_image“ 

der Klasse „Refinement“ definiert ist. Die KAOS-Methode sieht eine Unterscheidung 

zwischen And-Refinements (Und-Verfeinerungen) sowie Or-Refinements (Oder- 

Verfeinerungen) vor. Details hierzu können Abschnitt 2.1 sowie [KAOS07], 

[Lamsweerde09] und [Pohl10] entnommen werden. Und-Verfeinerungen werden 

dargestellt, indem mehrere Unterziele derselben Klasse vom Typ „Refinement“ mit 

jeweils einer Beziehung vom Typ „Refined By“ (siehe Abschnitt 3.3.2) zugeordnet 

werden. Die für die Unterziele gemeinsame Klasse „Refinement“ wird dann mit einer 

Beziehung vom Typ „Refinment Of“ (siehe Abschnitt 3.3.1) dem gemeinsamen Oberziel 

zugeordnet. Ein Beispiel für eine Und-Verfeinerung ist im Beispiel in Abb. 3–6 auf 

der rechten Seite dargestellt. 

Wenn mehrere Klassen vom Typ „Refinement“ demselben Oberziel (jeweils durch 

eine eigene Beziehung vom Typ „Refinement Of“) zugeordnet werden, stellt dies eine 

Oder-Verfeinerung dar. Jede Klasse von Typ „Refinement“ stellt eine Alternative Verfeinerung 

des gemeinsamen Oberzieles dar. Dabei ist zu beachten, dass jede Alternative 

ein oder mehrere Unterziele in einer Und-Verfeinerung zusammenschließen 

kann. In diesem Fall ist die Alternative nur dann vollständig erfüllt, wenn alle Unterziele 

erfüllt sind. 

3.3 Beziehungen zwischen den Elementen 

In diesem Abschnitt werden die Beziehungen zwischen den Modellelementen des 

KAOS-Zielmodells beschrieben, die im Paket „Goal Modeling Elements“ definiert 

wurden. Ein Überblick über das Paket kann aus Abschnitt 3.1.1 entnommen werden. 

Die Erläuterungen in den folgenden Abschnitten stützten sich auf Abb. 3–2. Die Verwendung 

der Beziehungen zwischen den Modellelementen ist in Abb. 3–6 illustriert. 

3.3.1 Die Beziehung „Refinement Of“ 

Die Klasse „Refinement Of“ spezifiziert eine Beziehung von einem Modellelement 

des Typs „Refinement“ zu einem Modellelement des Typs „Goal“. „Refinement Of“ 

erbt von er EA-Metaklasse „Generalization“. Die Beziehung „Refinement Of“ bedeutet, 

dass eine Menge von Unterzielen, die durch eine Menge von „Refined By“- 

Beziehungen einer Verfeinerung zugeordnet sind (siehe Abschnitt 3.3.2, sowie 

[KAOS07], [Lamsweerde09], [Pohl10]), alle erfüllt sein müssen, damit das Oberziel 

erfüllt ist. Nach KAOS ([KAOS07]) kann es lediglich eine „Refinement Of“-Beziehung 

zwischen einer Verfeinerung und einem Ziel geben. 

3.3.2 Die Beziehung „Refined By“ 

Die Klasse „Refined By“ spezifiziert eine Beziehung von einer Menge von Modellelementen 

des Typs „Goal“ zu einem Modellelement des Typs „Refinement“. Refined 

By“ erbt von er EA-Metaklasse „Association“. Die Beziehung „Refined By“ bedeutet, 

dass das Ziel ein Unterziel des Oberzieles ist, welchem die Verfeinerung zugeordnet 

ist (siehe Abschnitt 3.3.1, sowie [KAOS07], [Lamsweerde09], [Pohl10]). 

3.3.3 Die Beziehung „Contradiction“ 

Die Klasse „Contradiction“ spezifiziert eine Beziehung zwischen zwei Modellelementen 

des Typs „Goal“. Diese Beziehung sagt aus, dass sich zwei Ziele widersprechen, 

also das Erreichen eines Zieles das Erreichen eines anderen Zieles unmöglich 

macht. Ebenso wie die Beziehung „Refined By“ erbt die Beziehung „Contradiction“ 




von der EA-Metaklasse „Association“. Eine „Contradiction“-Beziehung wird als Bezier-Kurve 

zwischen beiden beteiligten Zielen dargestellt, wie durch das Attribut 

„_linestyle“ der Klasse „Contradiction“ festgelegt ist. 

3.3.4 Die Beziehung „Contribution“ 

Die Klasse „Contribution“ spezifiziert eine Beziehung zwischen zwei Modellelementen 

des Typs „Goal“. Diese Beziehung sagt aus, dass das Erreichen eines Zieles das 

Erreichen eines anderen Zieles beeinflusst. Die Art der Beeinflussung wird durch die 

Enumeration „ContributionType“ (siehe Abschnitt 3.4) spezifiziert, wie durch das Attribut 

„ContributionType“ der Klasse „Contribution“ festgelegt ist. Ebenso wie die Beziehung 

„Refined By“ und „Contradiction“ erbt die Beziehung „Contribution“ von der 

EA-Metaklasse „Association“. Eine „Contribution“-Beziehung wird als Bezier-Kurve 

zwischen beiden beteiligten Zielen dargestellt, wie durch das Attribut „_linestyle“ der 

Klasse „Contribution“ festgelegt ist. 

3.4 Die Enumerationen „GoalType“ und „ContributionType“ 

Die Enumerationen „ContributionType” und „GoalType” definieren Auswahllisten für 

so genannte „Tagged Values“ der Modellelemente. „Tagged Values“ werden in den 

Klassen, die Modellelemenete repräsentieren als Attribute definiert und können im 

EA-Editor im Eigenschaftsfenster über den Registerreiter „Tagged Values“ verwendet 

werden. 

Die Enumeration „GoalType“ wird von der Klasse „Goal“ verwendet (siehe Abschnitt 

3.2.1) und legt die drei Typen von Zielen fest („goal“, „softgoal“, „hardgoal“). Der Typ 

„goal“ ist der Standardtyp, der verwendet wird, wenn ein Ziel nicht genauer als „hardgoal“ 

(siehe Abschnitt 3.2.1.1) bzw. „softgoal“ (siehe Abschnitt 3.2.1.2) festgelegt 

wird. 

Die Enumeration „ContributionType“ wird von der Beziehung „Contribution“ verwendet 

(siehe Abschnitt 3.3.4) und legt fünf Intensitäten fest, mir der das Erreichen eines 

Zieles das Erreichen eines anderen Zieles Beeinflusst. Diese reichen von sehr 

schwach („--“) bis sehr stark („++“). 




4 Verwendung des MDG-Plug-Ins 

Das SysML Goal Modeling Profil wird in Form eines MDG-Plug-Ins (siehe [Sparx10]) 

für Enterprise Architect zur Verfügung gestellt. In diesem Abschnitt wird die Installation, 

Verwendung und Erweiterung des Profils kurz erläutert. Detaillierte Informationen 

zur MDG-Technologie, zur Verwendung und Erweiterung von UML/SysML-Profilen in 

Enterprise Architect und zur Modellierung mit Enterprise Architect werden in 

[Sparx09] und [Sparx10] erläutert. 


Dieses MDG-Plug-In befindet sich zusammen mit der Enterprise Architect Projektdatei 

des Profils im ZIP-Archiv „SysML-Goal-Modeling v4.zip“. Im Folgenden wird beschrieben, 

wie das SysML Goal Modeling-Profil in Enterprise Architect eingebunden 

werden kann. 

1. Entpacken der ZIP-Datei. Entpacken Sie die ZIP-Datei in einen Ordner auf der 

lokalen Festplatte. Es werden zwei Dateien entpackt: eine EAP-Datei und eine 

XML-Datei. 



3. Öffnen Sie den MDG-Technologie-Dialog. Klicken Sie dazu im Enterprise- 

Architect-Menü auf „Settings“ und danach auf die Menüoption „MDG Technologies“. 

4. Definieren Sie einen neuen MDG-Pfad. Im MDG-Technologie-Dialog, klicken sie 

auf „Avance“ und im darauf folgenden Fenster auf „Add“ und dann auf „Add 

Path…“. Geben Sie den Ordner an, in den Sie die ZIP-Datei in Schritt 1) entpackt 

haben. Der Zielordner ist der Ordner, in dem die XML-Datei entpackt wurde. Klicken 

Sie anschließend auf OK. Enterprise Architect wird Sie darauf hinweisen, 

dass die Änderungen erst nach einem Neustart übernommen werden. 


6. Überprüfen Sie, ob die MDG-Technologie eingebunden ist, indem Sie den 

MDG-Technologie-Dialog wie unter Schritt 4) öffnen. Es sollte nun unter „Technologies“ 

das SysML Goal Modeling-Plug-In aufgeführt werden. 




Im Folgenden wird beschrieben, wie das SysML Goal Modeling-Profil in Enterprise 

Architect verwendet werden kann. 


auf „File“ und dann „New Project“. Wählen Sie einen geeigneten Pfad und 

Dateinamen für die Projektdatei und klicken Sie auf „speichern“. 

2. Erstellen Sie ein neues Paket unter dem Wurzelknoten „Model“ im „Project 

Browser“. Verwenden Sie dazu entweder die „Add a Package“ oder drücken Sie 

„Strg+W“. Geben Sie dem Projekt einen geeigneten Nam und verwenden Sie 

„Class View“ als Sicht auf die Modelle in diesem Paket, wie in Abb. 4–1 dargestellt. 

Klicken Sie anschließend auf OK. 




Abb. 4–1 Screenshot zur Erstellung eines neuen Paketes für das Zielmodell 

3. Erstellen Sie ein neues Zieldiagramm, indem Sie mit der rechten Maustaste auf 

das in Schritt 2) erstellte Paket klicken und unter dem Menüeintrag „Add“ auf 

„New Diagram…“ klicken. Wählen Sie einen geeigneten Namen für Ihr Zieldiagramm 

und wählen Sie unter „Type“ die MDG-Technologie „SysML Goal Modeling“ 

aus. Wählen Sie anschließend unter „Diagram Types“ den Eintrag „Goal Diagram“. 

Abb. 4–2 zeigt die für diesen Schritt notwendigen Einstellungen. 

Abb. 4–2 Screenshot zur Erstellung eines neuen Zieldiagrammes 

4. Erstellen Sie ein Zieldiagramm im Enterprise Architect Editor. Genaue Informationen 

zur Verwendung von Enterprise Architect können aus [Sparx09] entnommen 

werden. Informationen zur Zielmodellierung mit KAOS können Sie in 




[KAOS07], [Lamsweerde09] und [Pohl10] finden. Abb. 4–3 zeigt ein Beispiel zur 

Modellierung mit dem Zieldiagramm. 

Abb. 4–3 Screenshot zur Modellierung der Ziele in dem neu erstellten Zieldiagramm 


Im Folgenden wird beschrieben, wie das SysML Goal Modeling-Profil in Enterprise 

Architect erweitert werden kann. 



XML-Datei. 

2. Öffnen Sie die EAP-Datei in Enterprise Architect. Starten Sie die Enterprise 

Architect Anwendung und öffnen Sie die EAP-Datei. Diese Datei enthält die Profildefinition 


3. Modellieren Sie Ihre Erweiterung zu. Nun können Sie Änderungen am Profil 

oder den Diagram- und Toolbox-Definitionen vornehmen oder weitere Profile hinzufügen. 

Hinweise zur Erweiterung von MDG-Technologien und zum Umgang mit 

Enterprise Architect können aus [Sparx09] und [Sparx10] entnommen werden. 





In diesem Dokument wurde das SysML Goal Modeling Profil für Enterprise Architect 

vorgestellt. Bei dem UML/SysML-Profil handelt es sich um eine MDG-Technologie, 

die als Plug-In für Enterprise Architect verwendet werden kann. Das Profil besteht 

aus drei Teilen: Der Definition des Zielmodellprofils im Paket „Goal Modeling Elements“, 

der Definition der Zieldiagramtypen im Paket „Goal Diagram Definition“ und 

der Definition für die User-Interface-Komponenten als EA-Toolbox im Paket „SysML 

Goal Modeling“. Das Profil definiert derzeit lediglich einen Ausschnitt der Modellierungselemente 

der KAOS-Methode. Im Profil werden zwei verschiedene Zielmodellelemente 

festgelegt: Ziele („Goals“) und Verfeinerungen („Refinements“). „Goals“ 

werden zur Modellierung von Zielen verwendet und als „hardgoal“ oder „softgoal“ 

genauer festgelegt. Verfeinerungen erlauben es, Unterziele zu Oberzielen zu definieren, 

sodass Oberziele mit Und-Verfeinerungen und Oder-Verfeinerungen durch Unterziele 

verfeinert werden. Dazu werden die Beziehungen „Refinement Of“ und „Refined 

By“ verwendet. Die zwei weiteren Beziehungen zwischen den Zielmodellelementen 

sind Widerspruch („Contradiction“) und Beeinflussung („Contribution“). Mit 

diesen beiden Beziehungen kann modelliert werden, inwiefern das Erreichen eines 

Zieles das Erreichen eines anderen Zieles beeinflusst oder verhindert. Verschiedene 

Typen der Beeinflussung sowie die verschiedenen Typen von Zielen werden durch 

zwei Enumerationen festgelegt. 

Zukünftige Arbeiten zu diesem Thema werden sich mit der Erweiterung dieses Profils 

und Plug-Ins zur Anwendung auf mehreren Abstraktionsstufen befassen.Des Weiteren 

soll das Profil um die übrigen Modellelemente der KAOS-Methode erweitert werden. 







D2.1.A, 2010. 

[FrMoSt09] Friedenthal, Sanford; Moore, Alan; Steiner, Rick. A Practical 

Guide to SysML. Morgan Kaufman & OMG, 2009. 

[KAOS07] Respect-IT. A KAOS Tutorial v1.0. 2007. 





[Lamsweerde09] van Lamsweerde, Axel. Requirements Engineering – From System 

Goals to UML Models to Software Specifications. Wiley, 2009. 




18.09.2009. 

[OMG10] Object Management Group. OMG Systems Modeling Language 


Number: formal/2010-06-02. 2010. 





Engineering. SPES 2020 Teilergebnis, Version 1.0 vom 

01.03.2010. 



2010. 


Anhang C – ZP-AP2 Teilergebnis: SysML-Profil und MDG- 

Plug-In für Enterprise Architect zur Szenariomodellierung 

auf Basis von SysML

- ZP-AP2 Teilergebnis: SysML-Profil und MDG-Plug-In für Enterprise Architect 

zur Szenariomodellierung auf Basis von SysML- 


Version: 1.0 


QS-Verantwortlich Raphael Weber (OFFIS) 





X Öffentlich 


X vorgelegt 

fertig gestellt


Erzeugung Nadezhda Avramova (NA), Bastian Tenbergen (BT) 



Änderung 


Geänderte 

Kapitel 



2 09.02.11 0.2 Alle Inhaltliche Vervollständigung NA In Bearbeitung 

3 10.02.11 0.3 Alle Inhaltliches Review & 

Überarbeitung 

BT In Bearbeitung 

4 14.02.11 0.3 Alle Internes Review MD In Bearbeitung 

5 15.02.11 0.4 Alle Überarbeitung BT Vorgelegt 

6 17.02.11 - - Externes Review OFFIS Vorgelegt 

7 01.03.11 0.5 1.1, 1.2, 2 Überarbeitung nach externem 

Review 

BT Vorgelegt 

8 01.03.11 0.6 1 Überarbeitung TW Vorgelegt 

9 02.03.11 1.0 Alle Finalisierung BT Fertig gestellt

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung 

auf Basis von SysML 

Kurzfassung 

Eine zu Beginn des SPES-Projekts durchgeführte Studie zum Stand der Praxis im 

modellbasierten Requirements Engineering ([LaGaSiTe10], [DaSiLa10]) hat gezeigt, 

dass die Betrachtung von Zielen und Szenarien sowie deren explizite Modellierung 

derzeit eine tendenziell eher untergeordnete Rolle im modellbasierten Requirements 

Engineering spielen. Zudem wurde im Rahmen der durchgeführten Befragung von 

den Industrieunternehmen mehrheitlich konstatiert, dass die systematische Verfeinerung 

von Anforderungen über mehrere Abstraktionsebenen eine Reihe von Potenzialen 

zur Verbesserung der Praxis im Requirements Engineering und zur Verbesserung 

von Entwicklungsprozess besitzt. Ziele dokumentieren die Begründungen für 

Anforderungen. Szenarien beschreiben exemplarische Ereignisfolgen, die zur Erfüllung 

bzw. zur expliziten Nichterfüllung eines Ziels führen. Für die systematische Erhebung 

und Verfeinerung von Anforderungen ist es für einen entsprechenden Ansatz 

wesentlich, Ziele durch Szenarien zu konkretisieren, um anhand der in den Szenarien 

dokumentierten Ereignisfolgen an der Systemgrenze, die detaillierten Anforderungen 

an den Entwicklungsgegenstand zu definieren. Im modellbasierten Requirements 

Engineering werden einzelne Szenarien unter anderem in Form von Sequenzdiagrammen 

der UML oder in Form von Message Sequence Charts (MSCs) 

dokumentiert (siehe [FrMoSt09]). Um die Anwendbarkeit von ziel- und szenariobasierten 

Requirements-Engineering-Ansätzen in der Praxis zu fördern, ist es dabei 

notwendig, eine geeignete Modellierungsunterstützung für kommerziell verfügbare 

Werkzeuge anzubieten. Das vorliegende Ergebnisdokument stellt die im Rahmen 

des SPES-Projekts entwickelte Unterstützung zur Modellierung von Szenarien im 

ziel- und szenariobasierten Requirements Engineering mit Hilfe des kommerziellen 

Werkzeugs Enterprise Architect vor 




Inhalt 




1.3 Überblick ....................................................................................................... 5 

2 Einführung zur Szenariomodellierung und UML/SysML ...................................... 7 

2.1 Szenariomodellierung .................................................................................... 7 

2.2 UML/SysML ................................................................................................... 8 


3 Beschreibung des MDG-Plug-Ins zur Szenariomodellierung in SysML ............... 9 

3.1 Überblick über das SysML-Profil ................................................................... 9 

3.2 Das Paket “SysML Scenario Diagram Definitions” ........................................ 9 

3.3 Das Paket “Scenario Modeling Elements” ................................................... 10 

3.4 Das Paket “SysML Scenario Modeling” ....................................................... 10 













„SysML Szenario Modeling“, welches ein Profil zur Modellierung von Use-Cases und 

Sequenzdiagrammen beinhaltet. Der Erweiterungsmechanismus mittels Profilen ist in 

der UML Superstucture spezifiziert (siehe [OMG10a] und [AvTe11]), jedoch handelt 

es sich bei dem vorliegenden Profil um ein SysML-Profil, da das vorliegende Profil im 

Speziellen auf der SysML-Sprache aufbaut. Es ist jedoch zu beachten, dass SysML 

selbst wiederum ein Profil der UML ist (vgl. [OMG10b0]). 

Das vorliegende Dokument ist das Zweite in einer Reihe von Dokumenten, die die 

Anforderungsartefakte des initialen, modellbasierten RE-Ansatzes ([LaSiStTe09]) in 

SysML-Profilen bereitstellt. Damit soll eine Grundlage für eine rudimentäre Werkzeugunterstützung 

für den initialen, modellbasierten RE-Ansatz gewährleistet werden. 

In einem abschließenden Deliverable D2.1C wird das integrierte Gesamtprofil 

mit allen Anforderungsartefakten für den initialen Ansatz vorgestellt. In diesem Ergebnisdokument 

wird isoliert das Profil zur Modellierung von Szenarien vorgestellt. 

Das vorliegende Dokument beschreibt den Aufbau des Plug-Ins, gibt eine Beschreibung 

der Architektur des SysML-Profils und erläutert die Verwendung des Profils in 

Enterprise Architect (EA) aus einer anwendungsnahen Sicht. 


In diesem Dokument wird ein SysML-Profil zur Szenariomodellierung auf Basis der 

Systems Modeling Language (SysML, siehe [OMG10b0]) vorgestellt. Dieses Profil 

wurde im Rahmen der Ausarbeitung zweier Fallstudien in Kooperation mit Bosch und 

EADS entwickelt und basiert auf den Ausführungen zur Szenariomodellierung aus 

dem initialen, modellbasierten Requirements Engineering Ansatz für Embedded Systems 

([LaSiStTe09]). Die Studie zum Stand der Praxis zum modellbasierten Requirements 

Engineering ([LaGaSiTe10], [DaSiLa10], [SiTePo10], [SiTePo11]) hat gezeigt, 

dass Ziel/Szenario-basiertes Vorgehen und Modellierung derzeit nur eine geringe 

Rolle im modellbasierten Requirements Engineering spielen. Ferner wurde gezeigt, 

dass durch die systematische Verfeinerung von Anforderungen auf mehreren 

Abstraktionsebenen Vorteile für das Requirements Engineering entstehen können. 

Zielen liegen Anforderungen zu Grunde und werden mit Szenarien erfüllt bzw. verfeinert. 

Für die systematische Erhebung und Verfeinerung von Anforderungen ist es 

daher unerlässlich, Ziele mit Hilfe von Szenarien zu konkretisieren. Im modellbasierten 

Requirements Engineering werden Szenarien in Szenario-Diagrammen 

([Pohl10]) modelliert, beispielsweise in Use-Case-Diagrammen oder Sequenzdiagrammen 

(siehe [FrMoSt09]). 


Im folgenden Abschnitt 2 wird eine kurze Einführung zur Szenario-Modellierung sowie 

zu UML/SysML gegeben. In Abschnitt 3 wird das EA-Plug-In „SysML Scenario 

Modeling“ erläutert, indem zunächst der Aufbau der zugehörigen EA-Projektdatei 

dargestellt wird (Abschnitt 3.1) und anschließend das SysML-Profil anhand seiner 

Implementierung in Enterprise Architect erläutert wird (Abschnitte 3.2 bis 3.4). In Abschnitt 

4 wird die Installation, Verwendung und Erweiterung des EA-Plug-In als MDG- 




Technologie erläutert. Eine Zusammenfassung dieses Dokumentes kann Abschnitt 5 

entnommen werden. 




2 Einführung zur Szenariomodellierung und UML/SysML 

2.1 Szenariomodellierung 

Szenarien sind konkrete Beispiele für Interaktionsfolgen mit oder innerhalb eines 

Systems. Sie bestehen aus Interaktionsschritten, die die Interaktionen des betrachteten 

Systems detailliert beschreiben. Außerdem spezifizieren Szenarien Informationen 

über den Kontext eines Systems, wie z.B. Akteure (Nutzer oder andere Systeme), 

Bedingungen, Örtlichkeiten und Ressourcen, die für die Ausführung eines Szenarios 

relevant sind. Da Szenarien wesentlich konkreter (in Bezug auf Interaktionsabfolgen) 

als andere Anforderungsmodelle sind, tragen sie zum Verständnis dieser bei. Szenarien 

werden mit Zielen an das System assoziiert. Die assoziierten Ziele werden durch 

Szenarien erfüllt (siehe [Pohl10]). 

Szenarien können entweder in textueller Form (strukturiert oder unstrukturiert), oder 

als Modelle dokumentiert werden. Die meistverwendeten Modellierungssprachen für 

die letztgenannte Kategorie sind Sequenzdiagramme und Use-Case-Diagramme, die 

sowohl in der UML als auch in der SysML bereits enthalten sind. 

Sequenzdiagramme repräsentieren einen Nachrichtenaustausch der beteiligten Akteure 

im Szenario in einer bestimmten Zeit. Ein Akteur kann eine Person, ein System 

oder Teile eines Systems repräsentieren. Unter jedem Akteur wird eine senkrechte 

Lebenslinie gezeichnet, die angibt, wann ein Akteur für das Senden oder Empfangen 

von Nachrichten bereit ist. Nachrichten in Sequenzdiagrammen können synchron 

oder asynchron gesendet werden. Beim ersten Typ wartet ein Akteur, der eine Nachricht 

an einem anderen Akteur gesendet hat, auf die entsprechende Antwort. Wenn 

der Nachrichtenaustausch asynchron erfolgt, wird keine Antwort erwartet. Darüber 

hinaus bieten Sequenzdiagramme die Möglichkeit, Nachrichtenaustausche, Alternativen, 

Ausnahmeinteraktionen und Referenzen zu anderen Sequenzdiagrammen, 

darstellen. (siehe [FrMoSt09]) 

Anders als die Sequenzdiagramme, können Use-Case-Diagramme keine Interaktionen 

zwischen den Akteuren darstellen. Durch das Konzept des Anwendungsfalles 

(engl.: Use Case) werden Mengen von konkreten Interaktionsschritten zusammengefasst 

und miteinander in Relation gestellt. Dadurch sind Use-Case-Diagramme gut 

geeignet, eine Übersicht über die möglichen Szenarien im Rahmen eines betrachteten 

Systems zu geben, und Aussagen über deren Beziehungen untereinander und 

mit beteiligten Akteuren zu treffen. In einem Use-Case-Diagramm werden die relevanten 

Use Cases durch eine Systemgrenze umrandet. Die Akteure, die außerhalb 

dieser Grenze stehen, werden mit den Use Cases verbunden, an denen sie sich beteiligen. 

Die Use Cases können untereinander auch Beziehungen aufweisen, die 

durch die Beziehungstypen „Generalisierung“, „Extend“ und „Include“ modelliert werden. 

Mit der Generalisierungsbeziehung wird dokumentiert, dass ein Use Case bestimmte 

Interaktionsschritte von einem anderen Use Case erbt. Die Extend- 

Beziehung gibt an, dass ein Use Case ein anderes um bestimmte Interaktionsschritte 

beim Eintritt eines Ereignisses erweitert. Durch die Include-Beziehung wird spezifiziert, 

dass ein Use Case Interaktionsschritte von einem anderen Use Case beinhaltet 

(siehe [Pohl10]). 




2.2 UML/SysML 

SysML ist eine universelle Sammlung, graphischer Modellierungssprachen zur Darstellung 

und Spezifikation von Verhaltens-, Zustands- und Strukturaspekten von Systemen 

([FrMoSt09], [OMG10b0]). SysML baut auf der Unified Modelling Language 

Version 2.0 (UML) auf. UML wird durch SysML domänenunabhängig erweitert und 

erlaubt es, ein System lösungsunabhängig zu spezifizieren. Szenariomodellierung 

wird in SysML durch die beiden Diagrammtypen „Use-Case-Diagramm“ und „Sequenzdiagramm“ 

ermöglicht. Das in diesem Ergebnisdokument beschriebene Profil 

für SysML stellt eine Einschränkung von SysML zur Modellierung von Szenarien dar. 


Die beiden Diagrammarten „Use-Case-Daigramm“ und „Sequenzdiagramm“ zur 

Spezifizierung von Szenarien werden als Grundlage für das SysML-Profil zur Szenariomodellierung 

verwendet. Da diese Diagrammtypen bereits Bestandteil von SysML 

sind, werden in einen Scenario-Viewpoint importiert (siehe Abb. 2–1). Da sich die 

Implementierung dieses Imports in Enterprise Architect technisch anders gestaltet als 

durch den in Abb. 2–1 dargestellten Mechanismus, wird die technische Implementation 

mit EA in Abschnitt 3 diskutiert. 

Abb. 2–1 Definition des SysML-Profils aus importierten Konzepten 




3 Beschreibung des MDG-Plug-Ins zur Szenariomodellierung 

in SysML 


SysML-Profil zur Modellierung von Szenarien implementiert wurde. Der nächste Unterabschnitt 

3.1 gibt einen Überblick über den Inhalt der entsprechenden Enterprise 

Architect (EA) Projektdatei. In den darauffolgenden Unterabschnitten 3.2 bis 3.4 werden 

die Bestandteile (und somit die technische Realisierung des Import- 

Mechanismus aus Abschnitt 2.3) des SysML-Profils erläutert. 

3.1 Überblick über das SysML-Profil 

Die EA-Projektdatei, die das SysML-Profil für Szenarien beschreibt, besteht aus drei 

Paketen, wie in Abb. 3–1 zu sehen ist. Sie werden in den folgenden Abschnitten erläutert. 

Deren Kennzeichnung gibt an, dass es sich bei dem jeweiligen 

Paket um eine benutzerdefinierte Erweiterung des SysML-Metamodells bzw. des 

Enterprise Architect Programmumfangs handelt. Eine Anleitung zur Erstellung von 

Erweiterungen in Enterprise Architect kann in [Sparx09] und [Sparx10] gefunden 

werden. 

Abb. 3–1 SysML-Paketdiagramm des UML/SysML-Profil für Szenarien 

3.2 Das Paket “SysML Scenario Diagram Definitions” 

Das Paket „SysML Scenario Diagram Definitions“ definiert die Diagrammtypen für die 

Sequenz- und Use-Case-Diagramme in Enterprise Architect. Wie in Abb. 3–1 zu sehen 

ist, hat das Paket „SysML Scenario Diagram Definitions“ vier Bestandteile („Diagram_Sequence“, 

„Diagram_Use Case“, „SysML Scenario Diagram“ und „SysML 

Use Case Diagram“). Eine detailliertere Sicht auf dieses Paket wird in Abb. 3–2 gegeben. 

Die oberen zwei Klassen „Diagram_Sequence“ und „Diagram_Use Case“ sind EA 

interne Klassen und beschreiben jeweils UML/SysML Sequenzdiagramme und 

UML/SysML Use-Case-Diagramme in Enterprise Architect. Die unten abgebildeten 

Klassen „SysML Scenario Diagram“ und „SysML Use Case Diagram“ sind benutzerdefinierte 

Stereotypen und erweitern die jeweiligen internen EA-Klasse. Durch die 

Vererbungsbeziehung wird spezifiziert, dass die Erweiterungsdiagramme jeweils Sequenzdiagramme 

und Use-Case-Diagramme als Grundlage benutzen. Mit dieser 

Vererbungsbeziehung wird die technische Umsetzung des in Abschnitt 2.3 erläuterten 

Import-Mechanismus erreicht. 

Eine Erläuterung der Attribute der EA-Klassen „Diagram_Sequence“ und „Diagram_Use 

Case“ kann [Sparx09] entnommen werden. Eine besondere Bedeutung 

hat das Attribut „toolbox“ in beiden Klassen, das die zu verwendete Toolbox für jeden 




Diagrammtyp angibt. Die Toolbox wird im Paket „SysML Scenario Modeling“ spezifiziert 

und wird näher in Abschnitt 3.4 erläutert. 

Abb. 3–2 UML-Klassendiagramm des Inhaltes des Paketes „Scenario Diagram Definitions“ 

3.3 Das Paket “Scenario Modeling Elements” 

Im Paket “Scenario Modeling Elements” können die zulässigen Modellelemente für 

das SysML-Profil zur Szenariomodellierung spezifiziert werden. Die Modellelemente 

sind bereits durch den Import der Diagramme festgelegt und bedürfen keiner weiteren 

Anpassung. Aus diesem Grund müssen keine neuen Modellelemente spezifiziert 

werden; es können die Vorhandenen im SysML-Profil verwendet werden. Das Paket 

„Scenario Modeling Elements“ bleibt daher leer und dient als Platzhalter für mögliche, 

spätere Erweiterungen. 

3.4 Das Paket “SysML Scenario Modeling” 

Im Paket “SysML Scenario Modeling” werden die GUI-Elemente für das erstellte 

SysML-Profil spezifiziert. Bei diesem Paket handelt es sich um ein technisches Profil, 

welches die sogenannte Enterprise Architect „Toolbox“ implementiert. Die Toolbox ist 

ein Teil des Enterprise Architect Diagramm-Editors, von dem die Modellelemente des 

verwendeten Diagramtyps ausgewählt werden können. Im Falle des SysML-Profils 

für Szenariomodellierung muss, ähnlich wie beim Paket „Scenario Modeling Elements“, 

keine neue Toolbox definiert werden. Da die in diesem SysML-Profil spezifizierten 

Sequenz- und Use-Case-Diagramme ein Bestandteil von UML und SysML 

sind, können ihre Toolboxen aus Enterprise Architect verwendet werden. Das Paket 

„SysML Sequence Diagram Toolbox Definition“ bleibt aus diesem Grund leer und 

dient als Platzhalter für eventuelle Erweiterungen (siehe Abb. 3–1). 

Abb. 3–3 zeigt Screenshots der Toolboxen für die Sequenzdiagramme und die Use- 

Case-Diagramme in Enterprise Architect. Diese werden immer automatisch geöffnet, 

sobald ein neues Sequenz- oder Use-Case-Diagramm in EA erstellt wird. Die Toolboxen 

können ebenfalls in einem beliebigen anderen Diagramm verwendet werden, 

wenn sie manuell nach einem Aufruf von „More tools…“ (siehe Abb. 3–3) aus dem 

Menü ausgewählt werden. 




Abb. 3–3 Screenhots der Toolboxen für Sequenz- und Use-Case-Diagramme in EA 





Das SysML Scenario Modeling Profile wird in Form eines MDG-Plug-Ins (siehe 

[Sparx10]) für Enterprise Architect zur Verfügung gestellt. In diesem Abschnitt wird 

die Installation, Verwendung und Erweiterung des Profils kurz erläutert. Detaillierte 

Informationen zur MDG-Technologie, zur Verwendung und Erweiterung von 

UML/SysML-Profilen in Enterprise Architect und zur Modellierung mit Enterprise Architect 

werden in [Sparx09] und [Sparx10] erläutert. 



des Profils im ZIP-Archiv „SysML-Scenario-Modeling v4.zip“. Im Folgenden wird 

beschrieben, wie das SysML Scenario Modeling Profile in Enterprise Architect eingebunden 

werden kann. 



XML-Datei. 





4. Definieren Sie einen neuen MDG-Pfad. Im MDG-Technologie-Dialog, klicken 

Sie auf „Advance“ und im darauf folgenden Fenster auf „Add“ und dann auf „Add 

Path…“. Geben Sie den Ordner an, in den Sie die ZIP-Datei in Schritt 1 entpackt 






MDG-Technologie-Dialog wie unter Schritt 4 öffnen. Es sollte nun unter „Technologies“ 

das SysML Scenario Modeling-Plug-In aufgeführt werden. 




Im Folgenden wird beschrieben, wie das SysML Scenario Modeling-Profil in Enterprise 

Architect verwendet werden kann. 






„Strg+W“. Geben Sie dem Projekt einen geeigneten Namen und verwenden Sie 

„Use Case“ oder „Dynamic“ als Sicht auf die Modelle in diesem Paket, wie in Abb. 

4–1 dargestellt. Klicken Sie anschließend auf OK. 




Abb. 4–1 Screenshot zur Erstellung eines neuen Paketes für die Szenariomodellierung 

3. Erstellen Sie ein neues Szenariodiagramm, indem Sie mit der rechten Maustaste 

auf das in Schritt 2) erstellte Paket klicken und unter dem Menüeintrag 

„Add“ auf „New Diagram…“ klicken. Wählen Sie einen geeigneten Namen für Ihr 

Zieldiagramm und wählen Sie unter „Type“ die MDG-Technologie „SysML Scenario 

Modeling“ aus. Wählen Sie anschließend unter „Diagram Types“ den Eintrag 

„SysML Scenario Diagram“ oder „SysML Use Case Diagram“. Abb. 4–2 zeigt die 

für diesen Schritt notwendigen Einstellungen. 

Abb. 4–2 Screenshot zur Erstellung eines neuen Szenariodiagrammes 

4. Erstellen Sie ein Szenariodiagramm im Enterprise Architect Editor. Genaue 

Informationen zur Verwendung von Enterprise Architect können aus [Sparx09] 

entnommen werden. Informationen zur Szenariomodellierung können Sie in 

[FrMoSt09] und [Pohl10] finden. Abb. 4–3 zeigt ein Beispiel zur Modellierung mit 

dem Zieldiagramm. 




Abb. 4–3 Screenshot zur Modellierung von Szenarien in einem Sequenzdiagramm 


Im Folgenden wird beschrieben, wie das SysML Scenario Modeling Profile in Enterprise 

Architect erweitert werden kann. 



XML-Datei. 





oder den Diagramm- und Toolbox-Definitionen vornehmen oder weitere Profile 

hinzufügen. Hinweise zur Erweiterung von MDG-Technologien und zum Umgang 

mit Enterprise Architect können aus [Sparx09] und [Sparx10] entnommen werden. 





In diesem Dokument wurde das SysML Scenario Modeling Profile für Enterprise Architect 

vorgestellt. Bei dem SysML-Profil handelt es sich um eine MDG-Technologie, 

die als Plug-In für Enterprise Architect verwendet werden kann. Das Profil besteht 

aus drei Teilen: Einem Platzhalter für die Modellierungselemente des Szenario- 

Profils im Paket „Scenario Modeling Elements“, der Definition der Szenariodiagramtypen 

im Paket „Scenario Diagram Definition“ und dem Platzhalter für die Definition 

für die User-Interface-Komponenten als EA-Toolbox im Paket „SysML Scenario 

Modeling“. Das Profil ist eine Einschränkung der SysML-Sprachfamilie hinsichtlich 

der Modellierung von Szenarien und importiert die Diagrammtypen „Sequenzdiagramm“ 

und „Use-Case-Diagramm“. Die technische Umsetzung dieses Imports in EA 

wurde zusammen mit der Erläuterung der Bestandteile des SysML Scenario Modelling-Profils 

beschrieben. 


und mit Plug-Ins zur Anwendung auf mehreren Abstraktionsstufen befassen. Weitere 

Arbeiten befassen sich mit der Erstellung eines Profils für lösungsorientierte Anforderungen, 

sowie einem Gesamtprofil, welches den gesamten, initialen modellbasierten 

RE-Ansatz abbildet. 





[AvTe11] Untersuchung des State-of-the-Art zur Erstellung von Domänenspezifischen 

Modellierungssprachen und UML/SysML-Profilen. 

SPES 2020 Teilergebnis des ZP-AP2, Version 1.0 vom 

09.02.2011 



D2.1.A, 2010. 






SPES 2020 Teilergebnis des ZP-AP2, Version 1.0 vom 

16.07.2010. 



Embedded Systems. SPES 2020 Teilergebnis des ZP-AP2, Version 

0.9 vom 18.09.2009. 

[OMG10a] Object Management Group: UML Superstructure Version 2.3, 


[OMG10b0] Object Management Group. OMG Systems Modeling Language 


Number: formal/2010-06-02. 2010. 





Engineering. SPES 2020 Teilergebnis des ZP-AP2, Version 

1.0 vom 01.03.2010. 

[SiTePo10] Sikora, E., Tenbergen, B., Pohl, K.: Modellbasiertes Requirements 

Engineering - Eine Situationsanalyse zum Stand der Praxis. Softwaretechnik 

Trends 30(1) (2010) 





REFSQ (2011) 



2010. 


Anhang D – ZP-AP2 Teilergebnis: SysML-Profil und MDG- 

Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten 

Anforderungen auf Basis von SysML

- ZP-AP2 Teilergebnis: SysML-Profil und MDG-Plug-In für Enterprise Architect 

zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML- 


Version: 1.1 


QS-Verantwortlich Jörg Holtmann (UPB) 





X Öffentlich 


vorgelegt 

X fertig gestellt


Erzeugung Sebastian Gabrisch (SG), Bastian Tenbergen (BT) 



Änderung 


Geänderte 

Kapitel 



2 03.03.11 0.2 2-3 Überarbeitung SG In Bearbeitung 

3 04.03.11 0.3 Alle Inhaltliche Überarbeitung BT In Bearbeitung 

4 17.03.11 - - Internes Review MD In Bearbeitung 

5 21.03.11 0.4 Alle Überarbeitung nach 

internem Review 

BT Vorgelegt 

6 05.04.11 - - Externes Review UPB Vorgelegt 

7 08.04.11 1.0 Alle Überarbeitung nach 

externem Review 

BT Fertig gestellt 

8 14.04.11 1.1 Alle Kleinere Verbesserungen BT Fertig gestellt

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von 

lösungsorientierten Anforderungen auf Basis von SysML 

Kurzfassung 

Eine zu Beginn des SPES-Projekts durchgeführte Studie zum Stand der Praxis im 

modellbasierten Requirements Engineering ([LaGaSiTe10], [DaSiLa10], [SiTePo11]) 

hat gezeigt, dass die Betrachtung und explizite Modellierung von lösungsorientierten 

Anforderungen in den drei Perspektiven Daten, Verhalten und Struktur (vgl. [Davis93] 

und [Pohl10]) derzeit eine tendenziell eher untergeordnete Rolle im modellbasierten 

Requirements Engineering spielen. Während die Diagrammarten zur Modellierung 

dieser Anforderungsartefakte häufige Verwendung während der Gewinnungs- und 

Abstimmungsphasen des RE finden, werden sie doch nicht durchgängig während 

des Gesamten RE-Prozesses, insbesondere zur Dokumentation verwendet; es fehlt 

an methodischer Anleitung und methodenbezogener Werkzeugunterstützung (siehe 

[SiTePo11]). Eine methodische Unterstützung wurde bereits durch den initialen RE- 

Ansatz [LaSiStTe09] zur Verfügung gestellt. Das in diesem Dokument beschriebene 

Profil zur Modellierung von lösungsorientierten Anforderungen stellt einen der Kernaspekte 

für eine Werkzeugunterstützung durch ein methodenspezifisches Profil dar. 

In vorangegangenen Arbeiten wurden bereits Profile für die Modellierung von Zielen 

und Szenarien mit dem Ziel vorgestellt, ein einheitliches, methodenspezifisches Profil 

für SysML zu entwickeln. Dieses Profil soll dem Anforderungsingenieur helfen, die für 

den initialen RE-Ansatz zu verwendenden Diagramme einfacher auszuwählen und 

anhand der Ansatzbeschreibung anzuwenden. Ferner wurde im Rahmen der durchgeführten 

Befragung von den Industrieunternehmen mehrheitlich konstatiert, dass 

die systematische Verfeinerung von Anforderungen über mehrere Abstraktionsebenen 

eine Reihe von Potenzialen zur Verbesserung der Praxis im Requirements Engineering 

und zur Verbesserung von Entwicklungsprozessen besitzt [SiTePo11]. Die 

durch Ziele und Szenarien dokumentierten Anforderungen werden durch lösungsorientierte 

Anforderungen verfeinert. Für die systematische Verfeinerung von Anforderungen 

ist es für einen entsprechenden Ansatz wesentlich, das Wirkungsgefüge des 

Systems in allen drei Perspektiven getrennt zu betrachten und auf Basis gemeinsamer 

Szenarien schrittweise Anforderungen an das System zu modellieren. Im modellbasierten 

Requirements Engineering werden lösungsorientierte Anforderungen in 

Form von Block-, Klassen-, oder EER-Diagrammen in der Datenperspektive modelliert. 

Lösungsorientierte Anforderungen in der Verhaltensperspektive werden mit Automatenmodellen, 

wie beispielsweise Input/Output-Automaten oder Statecharts modelliert. 

In der Funktionsperspektive dienen Aktivitätsdiagramme oder Datenflussdiagramme 

zur Modellierung. Die Modellierung von lösungsorientierten Anforderungen 

bildet zusammen mit der systematischen Erhebung von Zielen und Szenarien den 

Hauptfokus im initialen, modellbasierten Requirements-Engineering-Ansatz. Um die 

Anwendbarkeit von modellbasierten Requirements-Engineering-Ansätzen in der Praxis 

zu fördern, ist es dabei notwendig, eine geeignete Modellierungsunterstützung für 

kommerziell verfügbare Werkzeuge anzubieten. Das vorliegende Ergebnisdokument 

stellt die im Rahmen des SPES-Projekts entwickelte Unterstützung zur Modellierung 

von lösungsorientierten Anforderungen mit Hilfe des kommerziellen Werkzeugs 

Enterprise Architect vor. 




Inhalt 




1.3 Überblick ....................................................................................................... 6 

2 Einführung zur Modellierung lösungsorientierter Anforderungen und SysML ...... 7 

2.1 Modellierung von lösungsorientierten Anforderungen ................................... 7 

2.2 UML/SysML ................................................................................................... 7 


3 Beschreibung des Plug-Ins für lösungsorientierter Anforderungen in SysML .... 10 

3.1 Überblick über das SysML-Profil ................................................................. 10 

3.2 Das Paket “SysML Solution-Oriented Diagram Definitions” ......................... 10 

3.3 Das Paket “Solution-Oriented Modeling Elements” ..................................... 11 

3.4 Das Paket “SysML Solution-Oriented Modeling” ......................................... 11 











In diesem Abschnitt wird eine kurze Einordnung in den Projektkontext beschrieben 

und ein Überblick über den Dokumenteninhalt sowie den vorhergehenden Arbeiten 

gegeben. 



„SysML Solution-Oriented Modeling“, welches ein Profil zur Modellierung von lösungsorientierten 

Anforderungen in der Daten-, Verhaltens- und Funktionsperspektive 

unter Verwendung von State Machine Diagramme, Aktivitäts- und Blockdiagrammen 

beinhaltet. Der Erweiterungsmechanismus mittels Profilen ist in der UML Superstucture 

spezifiziert (siehe [OMG10a] und [AvTe11]). Allerdings handelt es sich bei 

dem vorliegenden Profil um ein SysML-Profil, da das vorliegende Profil insbesondere 

auf der SysML-Sprache aufbaut. Es ist jedoch zu beachten, dass SysML selbst wiederum 

ein Profil der UML ist (vgl. [OMG10a]). Das vorliegende Dokument ist das Dritte 

in einer Reihe von Dokumenten, die die Anforderungsartefakte des initialen, modellbasierten 

RE-Ansatzes ([LaSiStTe09]) in SysML-Profilen bereitstellen. Damit soll 

eine Grundlage für eine rudimentäre Werkzeugunterstützung für den initialen, modellbasierten 

RE-Ansatz gegeben werden. In einem abschließenden Deliverable 

D2.1C wird das integrierte Gesamtprofil mit allen Anforderungsartefakten für den initialen 

Ansatz vorgestellt. Das vorliegende Dokument beschreibt den Aufbau des 

Plug-Ins, gibt eine Beschreibung der Architektur des SysML-Profils und erläutert die 

Verwendung des Profils in Enterprise Architect (EA). 


In diesem Dokument wird ein SysML-Profil zur Modellierung lösungsorientierter Anforderungen 

auf Basis der Systems Modeling Language (SysML) vorgestellt. Dieses 

Profil wurde im Rahmen der Ausarbeitung zweier Fallstudien in Kooperation mit 

Bosch und EADS entwickelt und basiert auf den Ausführungen zur Modellierung lösungsorientierter 

Anforderungen aus dem initialen, modellbasierten Requirements 

Engineering Ansatz für Embedded Systems ([LaSiStTe09]). Die Studie zum Stand 

der Praxis zum modellbasierten Requirements Engineering ([LaGaSiTe10], [Da- 

SiLa10], [SiTePo10], [SiTePo11]) hat gezeigt, dass strukturierte Modellierung und 

Verfeinerung, der durch Ziele und Szenarien erhobenen Anforderungen, mittels lösungsorientierten 

Anforderungsmodellen derzeit nur eine geringe Rolle im modellbasierten 

Requirements Engineering spielen. Während die Diagrammarten zur Modellierung 

dieser Anforderungsartefakte häufige Verwendung während der Gewinnungs- 

und Abstimmungsphasen des RE finden, werden sie doch nicht durchgängig während 

des Gesamten RE-Prozesses, insbesondere zur Dokumentation verwendet; es 

fehlt an methodischer Anleitung und methodenbezogener Werkzeugunterstützung 

(siehe [SiTePo11]). Eine methodische Unterstützung wurde bereits durch den initialen 

RE-Ansatz [LaSiStTe09] zur Verfügung gestellt. Das in diesem Dokument beschriebene 

Profil zur Modellierung von lösungsorientierten Anforderungen stellt einen 

der Kernaspekte für eine Werkzeugunterstützung durch ein methodenspezifisches 

Profil dar. In vorangegangenen Arbeiten wurden bereits Profile für die Modellierung 

von Zielen und Szenarien mit dem Ziel vorgestellt, ein einheitliches, methodenspezifisches 

Profil für SysML zu entwickeln. Dieses Profil soll dem Anforderungsingenieur 

helfen, die für den initialen RE-Ansatz zu verwendenden Diagramme einfacher aus- 




zuwählen und anhand der Ansatzbeschreibung anzuwenden. Ferner wurde gezeigt, 

dass durch die systematische Verfeinerung von Anforderungen auf mehreren Abstraktionsebenen 

Vorteile für das Requirements Engineering entstehen können. Zielen 

liegen Anforderungen zu Grunde, sie werden von Szenarien erfüllt bzw. verfeinert. 

Die Szenarien werden ihrerseits durch lösungsorientierte Anforderungen in den drei 

Perspektiven „Daten“, „Verhalten“ und „Funktion“ verfeinert (vgl. [Davis93] und 

[Pohl10]). Im modellbasierten Requirements Engineering wird die Verhaltensperspektive 

in State Machine Diagrammen modelliert, die Datenperspektive in Blockdiagrammen, 

und die Funktionsperspektive in Aktivitätsdiagrammen ([FrMoSt09], 

[Pohl10]). 


Im folgenden Abschnitt 2 wird eine kurze Einführung zur Modellierung lösungsorientierter 

Anforderungen sowie zur UML/SysML gegeben. In Abschnitt 3 wird das EA- 

Plug-In „SysML Solution-Oriented Modeling“ erläutert, indem zunächst der Aufbau 

der zugehörigen EA-Projektdatei dargestellt wird (Abschnitt 3.1) und anschließend 

das SysML-Profil anhand seiner Implementierung in Enterprise Architect erläutert 

wird (Abschnitte 3.2 bis 3.4). In Abschnitt 4 wird die Installation, Verwendung und 

Erweiterung des EA-Plug-In als MDG-Technologie erläutert. Eine Zusammenfassung 

dieses Dokumentes kann Abschnitt 5 entnommen werden. 




2 Einführung zur Modellierung lösungsorientierter Anforderungen 

und SysML 

In diesem Abschnitt wird die Modellierung von lösungsorientierten Anforderungsartefakten 

kurz erläutert. Die Erläuterungen stützen sich auf die im initialen RE-Ansatz 

[LaSiStTe09] enthaltenen Erläuterungen zum Begriff der lösungsorientierten Anforderungen 

sowie dessen Modellierung. 

2.1 UML/SysML 

SysML ist eine universelle Sammlung, graphischer Modellierungssprachen zur Darstellung 

und Spezifikation von Verhaltens-, Zustands- und Strukturaspekten von Systemen 

([FrMoSt09], [OMG10a]). SysML baut auf der Unified Modeling Language 

Version 2.0 (UML, siehe [OMG10b]) auf. Während UML in der Softwaretechnik gängig 

ist, findet SysML Anwendung im Bereich des System Engineering. UML wird 

durch SysML fachdisziplinunabhängig erweitert und erlaubt es, ein System lösungsorientiert 

zu spezifizieren. Die Modellierung lösungsorientierter Anforderungen wird 

in SysML durch die drei Diagrammarten „State Machine Diagramm“, „Aktivitätsdiagramm“ 

und „Blockdiagramm“ ermöglicht. Das in diesem Ergebnisdokument beschriebene 

Profil für SysML stellt eine Einschränkung von SysML zur Modellierung 

lösungsorientierter Anforderungen dar. 

2.2 Modellierung von lösungsorientierten Anforderungen 

Lösungsorientierte Anforderungen spezifizieren die für die technische Umsetzung 

des Systems relevanten Details. Dabei werden sowohl die Anforderungen bezüglich 

der geforderten Funktionalität in Form von Daten, Funktionen und Verhalten, als 

auch Qualitätsaspekte des geplanten Systems abgedeckt. Die Gesamtmenge der 

lösungsorientierten Anforderungen sollte dabei im Hinblick auf die Realisierung des 

Systems möglichst vollständig, präzise und widerspruchsfrei sein (siehe [Pohl10]). 

Drei in der SysML vorhandene Diagrammtypen um lösungsorientierte Anforderungen 

zu modellieren sind State Machine Diagramme, Aktivitätsdiagramme und Blockdiagramme 

(siehe [OMG10a]). 

State Machine Diagramme in SysML modellieren das diskrete Verhalten eines Systems 

und wurden aus der UML-Spezifikation übernommen (siehe [OMG10a] und 

[OMG10b], Abschnitte 13.1 und 13.3). State Machines besitzen, so wie einfache Automaten, 

ebenfalls Zustände und Zustandsübergänge. Ein Zustand definiert hierbei 

eine Zeitspanne, in dem das modellierte System ein bestimmtes Verhalten zeigt. 

Durch das Eintreten eines definierten Ereignisses innerhalb dieses Zustandes wird 

dann ein Übergang in einen anderen Zustand ausgelöst, gekennzeichnet durch einen 

Pfeil zwischen den Zuständen. State Machine Diagramme bieten zudem die Möglichkeit 

zur Definition von Ereignissen und Bedingungen für Zustandsübergänge und 

zur Modellierung von Nebenläufigkeit. Darüber hinaus lässt sich durch hierarchische 

Zerlegung in Teilautomaten und „Superzustände“ die Komplexität der Betrachtung 

des Systems verringern (siehe [Pohl10]). 

Mit Aktivitätsdiagrammen lässt sich die funktionale Perspektive des Systems, bzw. 

der Kontrollfluss zwischen den diskreten und (in begrenztem Maße) kontinuierliche 

Aktivitäten eines Systems modellieren. Der Fokus bei dieser Art der Modellierung 

liegt dabei auf der Abfolge der Aktivitäten sowie auf den Daten- und Objektflüssen 

zwischen den Aktivitäten. Eine Aktivität kann dabei erst zu dem Zeitpunkt ausgeführt 

werden, wenn die im Kontrollfluss vorgelagerten Aktivitäten terminiert sind und alle 




einlaufenden Daten- und Objektflüsse zur Verfügung stehen. Die möglichen Pfade 

zwischen den Aktivitäten im System werden dabei durch die Daten- bzw. Kontrollflüsse 

modelliert. Aktivitätsdiagramme ermöglichen die Darstellung verschiedenster 

Verzweigungen von Kontrollflüssen, wie z.B. Nebenläufigkeit, Alternativen (sog. 

„Entscheidungsknoten“, i.d.R. mit Bedingungen verknüpft) und dem Zusammenführen 

von alternativen Kontrollflüssen (siehe [Pohl10]). 

In der Datenperspektive lassen sich verschiedene statische Strukturen des Systems 

modellieren, wie beispielsweise Datenentitäten, sowie deren Attribute und (siehe 

[Pohl10]). In der SysML existiert zur Datenmodellierung das Blockdiagramm. Dieses 

basiert auf dem UML-Klassendiagramm, sodass ebenfalls Assoziationen, Aggregationen, 

Kompositionen und Generalisierungen modelliert werden können. In der 

SysML wird ein Block allerdings als ein universelles Modellelement verstanden 

([OMG10a]), mit dem sowohl logische als auch physische Komponenten des Systems 

beschrieben werden können. In einem SysML-Blockdiagramm lassen sich die 

interne Struktur eines Blocks mit einer Vielzahl von möglichen Eigenschaften, als 

auch seine Verbindungen zu anderen Blöcken oder zu externen Akteuren beschreiben 

(siehe [OMG10a], [Sparx09]). 


Die drei Diagrammarten „State Machine Diagramm“, „Aktivitätsdiagramm“ und „Strukturdiagramm“ 

werden als Grundlage für das SysML-Profil zur Modellierung lösungsorientierter 

Anforderungen verwendet. Da diese Diagrammtypen bereits Bestandteil 

von SysML sind, werden sie in einen Viewpoint namens „Solution-Oriented- 

Requirements“ importiert (siehe Abb. 2–1). Da sich die Implementierung dieses Imports 

in Enterprise Architect technisch anders gestaltet als durch den in Abb. 2–1 

dargestellten Mechanismus, wird die technische Implementierung mit EA in Abschnitt 

3 diskutiert. 




Abb. 2–1 Definition des SysML-Profils aus importierten Konzepten 




3 Beschreibung des Plug-Ins für lösungsorientierter Anforderungen 

in SysML 


SysML-Profil zur Modellierung von lösungsorientierten Anforderungen implementiert 

wurde. Der nächste Unterabschnitt 3.1 gibt einen Überblick über den Inhalt der entsprechenden 

Enterprise Architect (EA) Projektdatei. In den darauffolgenden Unterabschnitten 

3.2 bis 3.4 werden die Bestandteile (und somit die technische Realisierung 

des Import-Mechanismus aus Abschnitt 2.3) des SysML-Profils erläutert. 

3.1 Überblick über das SysML-Profil 

Die EA-Projektdatei, die das SysML-Profil für lösungsorientierte Anforderungen beschreibt, 

besteht aus drei Paketen, wie in Abb. 3–1 zu sehen ist. Sie werden in den 

folgenden Abschnitten erläutert. Deren Kennzeichnung gibt an, dass es 

sich bei dem jeweiligen Paket um eine benutzerdefinierte Anpassung des SysML- 

Metamodells bzw. des Enterprise Architect Programmumfangs handelt. Eine Anleitung 

zur Erstellung von Erweiterungen in Enterprise Architect kann in [Sparx09] und 

[Sparx10] gefunden werden. 

Abb. 3–1 SysML-Paketdiagramm des UML/SysML-Profil für lösungsorientierte Anforderungen 

3.2 Das Paket “SysML Solution-Oriented Diagram Definitions” 

Das Paket „SysML Solution-Oriented Diagram Definitions“ definiert die Diagrammtypen 

für die Aktivitäts- und Blockdiagramme, sowie State Machine Diagramme in 

Enterprise Architect. Wie in Abb. 3–1 zu sehen ist, hat das Paket „SysML Solution- 

Oriented Diagram Definitions“ sechs Bestandteile („Diagram_Activity“, „Diagram_CompositeStructure“, 

„Diagram_Statechart“ „SysML Activity Diagram“ „SysML 

Internal Block Diagram“ und „SysML State Machine Diagram“). Eine detailliertere 

Sicht auf dieses Paket wird in Abb. 3–2 gegeben. 

Die oberen drei Klassen „Diagram_Activity“, „Diagram_CompositeStructure“, „Diagram_Statechart“ 

sind EA interne Klassen und beschreiben jeweils UML Aktivitätsdiagramme, 

UML Strukturdiagramme und UML State Machine Diagramme in Enterprise 

Architect. Die unten abgebildeten Klassen „SysML Activity Diagram“ „SysML Internal 

Block Diagram“ und „SysML State Machine Diagram“ sind benutzerdefinierte 

Klassen und erweitern die jeweiligen internen EA-Klasse. Durch die Vererbungsbeziehung 

wird spezifiziert, dass die Erweiterungsdiagramme jeweils Aktivitätsdiagramme, 

Strukturdiagramme und State Machine Diagramme als Grundlage benut- 




zen. Mit dieser Vererbungsbeziehung wird die technische Umsetzung des in Abschnitt 

2.3 erläuterten Import-Mechanismus erreicht. 

Eine Erläuterung der Attribute der Klassen „Diagram_Activity“, „Diagram_CompositeStructure“, 

„Diagram_Statechart“ kann [Sparx09] entnommen werden. 

Eine besondere Bedeutung hat das Attribut „toolbox“ in beiden Klassen, das die 

zu verwendende Toolbox für jeden Diagrammtyp angibt. Die Toolbox wird im Paket 

„SysML Solution-Oriented Modeling“ spezifiziert und wird näher in Abschnitt 3.4 erläutert. 

Abb. 3–2 UML-Klassendiagramm des Inhaltes des Paketes „Solution Oriented Diagram Definitions“ 

3.3 Das Paket “Solution-Oriented Modeling Elements” 

Im Paket „Solution-Oriented Modeling Elements” können die zulässigen Modellelemente 

für das SysML-Profil zur Modellierung von lösungsorientierten Anforderungen 

spezifiziert werden. Die Modellelemente sind bereits durch den Import der Diagramme 

festgelegt und bedürfen keiner weiteren Anpassung. Aus diesem Grund müssen 

keine neuen Modellelemente spezifiziert werden; es können die vorhandenen im 

SysML-Profil verwendet werden. Das Paket „Solution-Oriented Modeling Elements“ 

bleibt daher leer und dient als Platzhalter für mögliche, spätere Erweiterungen. 

3.4 Das Paket “SysML Solution-Oriented Modeling” 

Im Paket „SysML Solution-Oriented Modeling” werden die GUI-Elemente für das erstellte 

SysML-Profil spezifiziert. Bei diesem Paket handelt es sich um ein technisches 

Profil, welches die sogenannte Enterprise Architect „Toolbox“ implementiert. Die 

Toolbox ist ein Teil des Enterprise Architect Diagramm-Editors, von dem die Modellelemente 

des verwendeten Diagramtyps ausgewählt werden können. Im Falle 

des SysML-Profils für die Modellierung lösungsorientierter Anforderungen muss, ähnlich 

wie beim Paket „Solution-Oriented Modeling Elements“, keine neue Toolbox definiert 

werden. Da die in diesem SysML-Profil spezifizierten Aktivitäts-, Struktur- und 

Verhaltensdiagramme ein Bestandteil von SysML sind, können ihre Toolboxen aus 

Enterprise Architect verwendet werden. Das Paket „SysML Solution-Oriented Modeling 

Toolbox Definition“ bleibt aus diesem Grund leer und dient als Platzhalter für 

eventuelle Erweiterungen (siehe Abb. 3–1). 

Abb. 3–3 zeigt Screenshots der Toolboxen für State Machine Diagramme, Aktivitätsund 

Blockdiagramme in Enterprise Architect. Diese werden immer automatisch ge- 




öffnet, sobald ein neues Diagramm eines dieser drei Typen in EA erstellt wird. Die 

Toolboxen können ebenfalls in einem beliebigen anderen Diagramm verwendet werden, 

wenn sie manuell nach einem Aufruf von „More tools…“ (siehe Abb. 3–3) im 

Menü ausgewählt werden. 

Abb. 3–3 Screenshots der Toolboxen für die drei Modelltypen in EA 





Das SysML Solution-Oriented Modeling Profile wird in Form eines sogenannten 

MDG-Plug-Ins (siehe [Sparx10]) für Enterprise Architect zur Verfügung gestellt. In 

diesem Abschnitt wird die Installation, Verwendung und Erweiterung des Profils kurz 

erläutert. Detaillierte Informationen zur MDG-Technologie, zur Verwendung und Erweiterung 

von UML/SysML-Profilen in Enterprise Architect und zur Modellierung mit 

Enterprise Architect werden in [Sparx09] und [Sparx10] erläutert. 



des Profils im ZIP-Archiv „SysML- Solution-Oriented-Modeling v4.zip“. Im Folgenden 

wird beschrieben, wie das SysML Solution-Oriented-Modeling-Profil in Enterprise 

Architect eingebunden werden kann. 



XML-Datei. 





4. Definieren Sie einen neuen MDG-Pfad. Im MDG-Technologie-Dialog, klicken 

Sie auf „Advance“ und im darauf folgenden Fenster auf „Add“ und dann auf „Add 

Path…“. Geben Sie den Ordner an, in den Sie die ZIP-Datei in Schritt 1 entpackt 






MDG-Technologie-Dialog wie unter Schritt 4 öffnen. Es sollte nun unter „Technologies“ 

das SysML Solution-Oriented Modeling-Plug-In aufgeführt werden. 




Im Folgenden wird beschrieben, wie das SysML Solution-Oriented Modeling-Profil in 

Enterprise Architect verwendet werden kann. 






„Strg+W“. Geben Sie dem Projekt einen geeigneten Namen und verwenden Sie 

„Dynamic“ als Sicht auf die Modelle in diesem Paket, wie in Abb. 4–1 dargestellt. 

Klicken Sie anschließend auf OK. 




Abb. 4–1 Screenshot zur Erstellung eines neuen Paketes für die Modellierung 

lösungsorientierter Anforderungen 

3. Erstellen Sie ein neues Diagramm für lösungsorientierte Anforderungen, 

indem Sie mit der rechten Maustaste auf das in Schritt 2) erstellte Paket klicken 

und unter dem Menüeintrag „Add“ auf „Add Diagram…“ klicken. Wählen Sie einen 

geeigneten Namen für Ihr Zieldiagramm und wählen Sie unter „Type“ die MDG- 

Technologie „SysML Solution-Oriented Modeling“ aus. Wählen Sie anschließend 

unter „Diagram Types“ den Eintrag „SysML Activity Diagram“, „SysML Internal 

Block Diagram“ oder „SysML State Machine Diagram“. Abb. 4–2 zeigt die für diesen 

Schritt notwendigen Einstellungen. 

Abb. 4–2 Screenshot zur Erstellung eines neuen Aktivitätsdiagrammes 

4. Erstellen Sie ein Diagramm für lösungsorientierte Anforderungen im Enterprise 

Architect Editor. Genaue Informationen zur Verwendung von Enterprise Architect 

können aus [Sparx09] entnommen werden. Informationen zur Modellierung 

lösungsorientierter Anforderungen können Sie in [Davis93] und [Pohl10] finden. 

Abb. 4–3 zeigt ein Beispiel zur Modellierung eines Aktivitätsdiagrammes. 




Abb. 4–3 Screenshot zur Modellierung von lösungsorientierten Anforderungen 

in einem Aktivitätsdiagramm 


Im Folgenden wird beschrieben, wie das SysML Solution-Oriented Modeling Profil in 

Enterprise Architect erweitert werden kann. 



XML-Datei. 





oder den Diagramm- und Toolbox-Definitionen vornehmen oder weitere Profile 

hinzufügen. Hinweise zur Erweiterung von MDG-Technologien und zum Umgang 

mit Enterprise Architect können aus [Sparx09] und [Sparx10] entnommen werden. 





In diesem Dokument wurde das SysML Solution-Oriented Modeling Profile für Enterprise 

Architect vorgestellt. Bei dem SysML-Profil handelt es sich um eine MDG- 

Technologie, die als Plug-In für Enterprise Architect verwendet werden kann. Das 

Profil besteht aus drei Teilen: Einem Platzhalter für die Modellierungselemente des 

Profils für lösungsorientierte Anforderungen im Paket „Solution-Oriented Modeling 

Elements“, der Definition der Diagrammtypen im Paket „Solution-Oriented Diagram 

Definition“ und dem Platzhalter für die Definition für die User-Interface-Komponenten 

als EA-Toolbox im Paket „SysML Solution-Oriented Modeling“. Das Profil ist eine 

Einschränkung der SysML-Sprachfamilie hinsichtlich der Modellierung von lösungsorientierten 

Anforderungen und importiert die Diagrammtypen „State Machine Diagramm“ 

„Aktivitätsdiagramm“ und „internes Blockdiagramm“. Die technische Umsetzung 

dieses Imports in EA wurde zusammen mit der Erläuterung der Bestandteile 

des SysML Solution-Oriented Modelling-Profils beschrieben. 


und mit Plug-Ins zur Anwendung auf mehreren Abstraktionsstufen befassen. Weitere 

Arbeiten befassen sich mit der Erstellung eines Gesamtprofils, welches den gesamten 

modellbasierten RE-Ansatz abbildet. 





[AvTe11] Untersuchung des State-of-the-Art zur Erstellung von Domänenspezifischen 

Modellierungssprachen und UML/SysML-Profilen. 

SPES 2020 Teilergebnis des ZP-AP2, Version 1.0. 



D2.1.A, 2010. 

[Davis93] Davis, A. M.: Software Requirements – Objects, Functions, and 

States. 2 nd Edition. Prentice Hall (1993) 










18.09.2009. 

[OMG10a] Object Management Group. OMG Systems Modeling Language 


Number: formal/2010-06-02. 2010. 

[OMG10b] Object Management Group: UML Superstructure Version 2.3, 






Engineering. SPES 2020 Teilergebnis, Version 1.0. 

[SiTePo10] Sikora, E., Tenbergen, B., Pohl, K.: Modellbasiertes Requirements 

Engineering - Eine Situationsanalyse zum Stand der Praxis. Softwaretechnik 

Trends 30(1) (2010) 





REFSQ (2011) 



2010.

download - SPES 2020

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?