Zusammenfassendes Deliverable D2.1C: SysML Profil für Enterprise Architect zur Modellierung modellbasierter Anforderungen im SPESRequirements View Version: 1.0

Projektbezeichnung

SPES 2020

Verantwortlich

Bastian Tenbergen

QS-Verantwortlich

Siehe Teilergebnisse im Anhang

Erstellt am

11.04.2011

Zuletzt geändert

06.06.2011 15:24 Vertraulich für Partner: ; ; …

Freigabestatus

Projektöffentlich X Bearbeitungszustand

Öffentlich 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

Geänderte Kapitel

Beschreibung der Änderung

Autor

Zustand

Nr.

Datum

Version

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 REAnsatzes [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

2

3

4

Einordnung und Kurzbeschreibung ............................................................... 5 1.1

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

1.2

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

1.3

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

Ü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

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

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

3.2

Zusammenfassung ............................................................................... 14

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 5

6

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

Das Gesamtprofil SysML-Profil ................................................................... 21 5.1

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

5.2

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

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

Zuletzt geändert: 06.06.2011 15:24

4/34

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 RequirementsEngineering-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 beschrieZuletzt geändert: 06.06.2011 15:24

5/34

benen 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.

Zuletzt geändert: 06.06.2011 15:24

6/34

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 RequirementsEngineering-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] Zuletzt geändert: 06.06.2011 15:24

7/34

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]

Zuletzt geändert: 06.06.2011 15:24

8/34

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.

Zuletzt geändert: 06.06.2011 15:24

9/34

stm 2.2.3.1. States "Transportation Controller" Activ ated

Automatic Mode

!AutoMode OperationOn AutoMode

Initial

Manual Mode

Initial

!OperationOn

OperationOn

Deactiv ated

Final

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"

Functions of Transportation Controller

Movement Instruction Crane1

Compute Waypoint for Crane1 Crane1 Action

Crane1 Action

Crane2 Action

Crane2 Action

Movement Instruction Crane1 Compute Waypoint for Crane2

Process Sensor Data Automatic Mode

Sensor

Movement Instruction Crane2

Automatic Mode

Sensor Operation On

Movement Instruction Crane2

Compute Mov ement of Conv eyor

Operation On

Operation On

SupplyConveyor

SupplyConveyor

DeliveryConveyor

DeliveryConveyor

Abbildung 5: Ein SysML Aktivitätsdiagramm als Beispiel für ein Funktionsmodell [SPES11f] Zuletzt geändert: 06.06.2011 15:24

10/34

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 Verbesserungsbzw. 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 ArteZuletzt geändert: 06.06.2011 15:24

11/34

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]

Zuletzt geändert: 06.06.2011 15:24

12/34

3

Modellunterstützung für den Requirements View

Das Ziel des im Rahmen von SPES 2010 zu entwickelnden RequirementsEngineering-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-EngineeringAnsatz 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 SPESProjektes 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 Zuletzt geändert: 06.06.2011 15:24

13/34

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 UMLProfilmechanismus 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/SysMLMetamodell 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 REAnsatz 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 Zuletzt geändert: 06.06.2011 15:24

14/34

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.

Zuletzt geändert: 06.06.2011 15:24

15/34

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 („SubZuletzt geändert: 06.06.2011 15:24

16/34

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. Zuletzt geändert: 06.06.2011 15:24

17/34

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 UML/SysML Metamodell

der

Methodenkonzepte

in

das

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 KAOSFrameworks (vgl. [RespIT07] und [VaLa09]) implementiert, da diese die größte KomZuletzt geändert: 06.06.2011 15:24

18/34

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 ContainmentBeziehung, 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 Zuletzt geändert: 06.06.2011 15:24

19/34

Der Stereotyp „Refinement“ kann dazu verwendet werden UND- sowie ODERBeziehungen 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 „ContributionType“ beschrieben werden. Details zu Zielbeziehungen können ebenfalls in [RespIT07] gefunden werden.

Zuletzt geändert: 06.06.2011 15:24

20/34

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 KAOSMethode. 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.

Zuletzt geändert: 06.06.2011 15:24

21/34

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 SolutionOriented 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 DiaZuletzt geändert: 06.06.2011 15:24

22/34

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].

Zuletzt geändert: 06.06.2011 15:24

23/34

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 ArchitecZuletzt geändert: 06.06.2011 15:24

24/34

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.

Zuletzt geändert: 06.06.2011 15:24

25/34

6

Kurzanleitung: Installation und Verwendung des Profils

Das Gesamtprofil des Requirements Views wird in Form eines sogenannten MDGPlug-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-ArchitectMenü 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 MDGTechnologie-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 DiaZuletzt geändert: 06.06.2011 15:24

26/34

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.

Zuletzt geändert: 06.06.2011 15:24

27/34

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 EAProfil 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.

Zuletzt geändert: 06.06.2011 15:24

28/34

8

Referenzen

[Davis93]

Davis, A. M.: Software Requirements – Objects, Functions, and States. 2nd 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-

Zuletzt geändert: 06.06.2011 15:24

29/34

Plug-In für Enterprise Architect zur Modellierung von KAOSZieldiagrammen 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

Zuletzt geändert: 06.06.2011 15:24

30/34

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

Version: 1.0

Projektbezeichnung

SPES 2020

Verantwortlich

Bastian Tenbergen

QS-Verantwortlich

Raphael Weber (OFFIS)

Erstellt am

13.12.2010

Zuletzt geändert

09.02.2011 09:59 Vertraulich für Partner: ; ; …

Freigabestatus

Projektöffentlich X Bearbeitungszustand

Öffentlich in Bearbeitung vorgelegt

X

fertig gestellt

Weitere Produktinformationen Erzeugung

Nadezhda Avramova (NA), Bastian Tenbergen (BT)

Mitwirkend

Marian Daun (MD), Thorsten Weyer (TW)

Änderungsverzeichnis Änderung

Geänderte Kapitel

Beschreibung der Änderung

Autor

Zustand

Nr.

Datum

Version

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.

Zuletzt geändert: 09.02.2011 09:59

3/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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

4

5

3.1

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

3.2

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

3.3

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

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

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

Zuletzt geändert: 09.02.2011 09:59

4/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

1

Einordnung und Kurzbeschreibung

1.1 Motivation und Einordnung 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.

1.2 Management Summary 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.

1.3 Überblick 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.

Zuletzt geändert: 09.02.2011 09:59

5/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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.

Zuletzt geändert: 09.02.2011 09:59

6/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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 SoftwareProdukte 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 Zuletzt geändert: 09.02.2011 09:59

7/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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. Zuletzt geändert: 09.02.2011 09:59

8/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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 UMLKlassendiagramm 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 Zuletzt geändert: 09.02.2011 09:59

9/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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.

Zuletzt geändert: 09.02.2011 09:59

10/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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. SysMLProfile sind folglich auch UML-Profile, jedoch nicht umgekehrt. UML-Profile sind domänenspezifische Erweiterungen von bestehenden UMLMetamodellelementen. 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.

Zuletzt geändert: 09.02.2011 09:59

11/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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 UMLMetamodellelementen 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 UMLProfils 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-ExtensionAnsatz 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 Zuletzt geändert: 09.02.2011 09:59

12/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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 UMLProfils 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.

Zuletzt geändert: 09.02.2011 09:59

13/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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 Zuletzt geändert: 09.02.2011 09:59

14/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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 SoftwareKomponenten. Der Hardwarearchitekturblock dient zur Modellierung der Hardwarekomponenten. Der Block der dynamischen Architektur repräsentiert SoftwareThreads 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. SoCZuletzt geändert: 09.02.2011 09:59

15/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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 UMLProfil 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 UMLModel mit QoS-Eigenschaften heißt Quality Model. Darüber hinaus enthält das QoSProfil 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.

Zuletzt geändert: 09.02.2011 09:59

16/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

6

Zusammenfassung

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.

Zuletzt geändert: 09.02.2011 09:59

17/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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 modellbasierten Requirements Engineering. SPES 2020 Deliverable 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, 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.

[LaSiStTe09]

Lauenroth, Kim; Sikora, Ernst; Stallbaum, Heiko; Tenbergen, Bastian. Initialer modellbasierter Requirements Engineering Ansatz für Embedded Systems. SPES 2020 Teilergebnis, Version 0.9 vom 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-

Zuletzt geändert: 09.02.2011 09:59

18/19

Untersuchung des State-of-the-Art zur Erstellung von domänenspezifischen Modellierungssprachen und UML/SysML-Profilen

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)

[Pohl10]

Pohl, Klaus. Requirements Engineering – Foundations, Principles, Techniques. Springer, 2010.

[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 RealTime 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 17th 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.

Zuletzt geändert: 09.02.2011 09:59

19/19

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

Projektbezeichnung

SPES 2020

Verantwortlich

Bastian Tenbergen (Universität Duisburg-Essen)

QS-Verantwortlich

Tayfun Gezgin (OFFIS e.V.)

Erstellt am

05.09.2010

Zuletzt geändert

13.10.2010 11:14 Vertraulich für Partner: ; ; …

Freigabestatus

Projektöffentlich X Bearbeitungszustand

Öffentlich in Bearbeitung vorgelegt

X

fertig gestellt

Weitere Produktinformationen Erzeugung

Bastian Tenbergen (BT), Marian Daun (MD)

Mitwirkend

Ernst Sikora (ES), Heiko Stallbaum (HS), Tayfun Gezgin (TG)

Änderungsverzeichnis Änderung Nr.

Datum

Version

1

05.09.10

0.1

2

07.09.10

3

07.09.10

4

30.09.10

5

05.10.10

6

07.10.10

7

13.10.10

1.0

1.1

1.2

Geänderte Kapitel

Beschreibung der Änderung

Autor

Zustand

Alle

Initiale Produkterstellung

BT

In Bearbeitung

Interner Review

ES

In Bearbeitung

Editorielle Überarbeitung

BT

Vorgelegt

Externer Review

TG

Vorgelegt

Überarbeitung nach externem Review

BT

In Bearbeitung

Interner Review

HS

In Bearbeitung

Überarbeitung

BT

Fertig gestellt

Alle

Alle

Alle

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 KAOSMethode es vorsieht ([KAOS07], [Lamsweerde09]).

Zuletzt geändert: 13.10.2010 11:14

3/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML

Inhalt 1

2

3

4

5 6

Einordnung und Kurzbeschreibung ..................................................................... 5 1.1 Motivation und Einordnung ............................................................................ 5 1.2 Management Summary ................................................................................. 5 1.3 Überblick ....................................................................................................... 5 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 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 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 Zusammenfassung ............................................................................................ 19 Literaturverzeichnis ........................................................................................... 20

Zuletzt geändert: 13.10.2010 11:14

4/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML

1 Einordnung und Kurzbeschreibung 1.1 Motivation und Einordnung 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).

1.2 Management Summary 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 KAOSMethode es vorsieht ([KAOS07], [Lamsweerde09]).

1.3 Überblick 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 EAProjektdatei 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 EAPlug-In als MDG-Technologie erläutert. Eine Zusammenfassung dieses Dokumentes kann Abschnitt 5 entnommen werden.

Zuletzt geändert: 13.10.2010 11:14

5/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML

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 UndVerfeinerungen (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/SysMLProfil 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. Zuletzt geändert: 13.10.2010 11:14

6/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML

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.

Zuletzt geändert: 13.10.2010 11:14

7/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML

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-Profil1 Wie in Abb. 3–12 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. SysML1

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. Zuletzt geändert: 13.10.2010 11:14

8/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML 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 Zuletzt geändert: 13.10.2010 11:14

9/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML 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 PaketNotationsform (siehe dazu [Sparx10] und [OMG10] beschrieben.

Zuletzt geändert: 13.10.2010 11:14

10/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML

Abb. 3–4 UML-Klassendiagramm des Inhaltes des Paketes „SysML Goal Modeling“

Die folgende Abb. 3–53 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 Mo3

Alle Screenshots in diesem Dokument zeigen Ausschnitte aus dem Programm „Enterprise Architect“ (EA) von SparxSystems. Zuletzt geändert: 13.10.2010 11:14

11/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML 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 UndVerfeinerung 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 Zuletzt geändert: 13.10.2010 11:14

12/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML 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 OderVerfeinerungen in einem Zieldiagramm dar. Klassen vom Typ „Refinement“ haben Zuletzt geändert: 13.10.2010 11:14

13/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML 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 (OderVerfeinerungen) 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“ Zuletzt geändert: 13.10.2010 11:14

14/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML 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 („++“).

Zuletzt geändert: 13.10.2010 11:14

15/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML

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.

4.1 Installation der MDG-Technologie 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. 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 EnterpriseArchitect-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. 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 SysML Goal Modeling-Plug-In aufgeführt werden. Weitere Möglichkeiten zur Einbindung von MDG-Plug-Ins in Enterprise Architect sind in [Sparx10] erläutert.

4.2 Verwendung des Profils Im Folgenden wird beschrieben, wie das SysML Goal Modeling-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 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.

Zuletzt geändert: 13.10.2010 11:14

16/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML

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

Zuletzt geändert: 13.10.2010 11:14

17/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML [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

4.3 Erweiterung des Profils Im Folgenden wird beschrieben, wie das SysML Goal 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-Datei 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 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.

Zuletzt geändert: 13.10.2010 11:14

18/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML

5 Zusammenfassung 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.

Zuletzt geändert: 13.10.2010 11:14

19/20

UML/SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML

6 Literaturverzeichnis [DaSiLa10]

Daun, Marian; Sikora, Ernst; Lauenroth, Kim. Stand der Praxis im modellbasierten Requirements Engineering. SPES 2020 Deliverable 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. [LaGaSiTe10] 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. [Lamsweerde09] van Lamsweerde, Axel. Requirements Engineering – From System Goals to UML Models to Software Specifications. Wiley, 2009. [LaSiStTe09] Lauenroth, Kim; Sikora, Ernst; Stallbaum, Heiko; Tenbergen, Bastian. Initialer modellbasierter Requirements Engineering Ansatz für Embedded Systems. SPES 2020 Teilergebnis, Version 0.9 vom 18.09.2009. [OMG10] Object Management Group. OMG Systems Modeling Language (OMG SysML) Language Specification v1.2. OMG Document Number: formal/2010-06-02. 2010. [Pohl10] Pohl, Klaus. Requirements Engineering – Foundations, Principles, Techniques. Springer, 2010. [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. [Sparx09] SparxSystems. Enterprise Architect User Guide. 2009. [Sparx10] SparxSystems. Enterprise Architect Software Developers’ Kit. 2010.

Zuletzt geändert: 13.10.2010 11:14

20/20

Anhang C – ZP-AP2 Teilergebnis: SysML-Profil und MDGPlug-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

Projektbezeichnung

SPES 2020

Verantwortlich

Bastian Tenbergen (Universität Duisburg-Essen)

QS-Verantwortlich

Raphael Weber (OFFIS)

Erstellt am

05.01.2011

Zuletzt geändert

02.03.2011 11:26 Vertraulich für Partner: ; ; …

Freigabestatus

Projektöffentlich X Bearbeitungszustand

Öffentlich in Bearbeitung

X

vorgelegt fertig gestellt

Weitere Produktinformationen Erzeugung

Nadezhda Avramova (NA), Bastian Tenbergen (BT)

Mitwirkend

Marian Daun (MD), Thorsten Weyer (TW)

Änderungsverzeichnis Änderung

Geänderte Kapitel

Beschreibung der Änderung

Autor

Zustand

Nr.

Datum

Version

1

05.01.11

0.1

Alle

Initiale Produkterstellung

BT

In Bearbeitung

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

Zuletzt geändert: 02.03.2011 11:26

3/16

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML Inhalt 1 Einordnung und Kurzbeschreibung ..................................................................... 5 1.1 Motivation und Einordnung ............................................................................ 5 1.2 Management Summary ................................................................................. 5 1.3 Überblick ....................................................................................................... 5 2 Einführung zur Szenariomodellierung und UML/SysML ...................................... 7 2.1 Szenariomodellierung .................................................................................... 7 2.2 UML/SysML ................................................................................................... 8 2.3 Hinweise zur Implementierung des SysML-Profils mit EA ............................. 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 4 Verwendung des MDG-Plug-Ins ........................................................................ 12 4.1 Installation der MDG-Technologie ............................................................... 12 4.2 Verwendung des Profils ............................................................................... 12 4.3 Erweiterung des Profils ................................................................................ 14 5 Zusammenfassung ............................................................................................ 15 6 Literaturverzeichnis ........................................................................................... 16

Zuletzt geändert: 02.03.2011 11:26

4/16

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML

1 Einordnung und Kurzbeschreibung 1.1 Motivation und Einordnung Das vorliegende Ergebnisdokument beschreibt das Enterprise Architect Plug-In „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.

1.2 Management Summary 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]).

1.3 Überblick 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-

Zuletzt geändert: 02.03.2011 11:26

5/16

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML Technologie erläutert. Eine Zusammenfassung dieses Dokumentes kann Abschnitt 5 entnommen werden.

Zuletzt geändert: 02.03.2011 11:26

6/16

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML

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 ExtendBeziehung 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]).

Zuletzt geändert: 02.03.2011 11:26

7/16

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML

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.

2.3 Hinweise zur Implementierung des SysML-Profils mit EA 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

Zuletzt geändert: 02.03.2011 11:26

8/16

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML

3 Beschreibung des MDG-Plug-Ins zur Szenariomodellierung in SysML In diesem Abschnitt wird das Enterprise Architect Plug-In beschrieben, in dem das 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 ImportMechanismus 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

Zuletzt geändert: 02.03.2011 11:26

9/16

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML 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 UseCase-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.

Zuletzt geändert: 02.03.2011 11:26

10/16

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML

Abb. 3–3 Screenhots der Toolboxen für Sequenz- und Use-Case-Diagramme in EA

Zuletzt geändert: 02.03.2011 11:26

11/16

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML

4 Verwendung des MDG-Plug-Ins 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.

4.1 Installation der MDG-Technologie Dieses MDG-Plug-In befindet sich zusammen mit der Enterprise Architect Projektdatei 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. 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. 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 EnterpriseArchitect-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 SysML Scenario Modeling-Plug-In aufgeführt werden. Weitere Möglichkeiten zur Einbindung von MDG-Plug-Ins in Enterprise Architect sind in [Sparx10] erläutert.

4.2 Verwendung des Profils Im Folgenden wird beschrieben, wie das SysML Scenario Modeling-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 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.

Zuletzt geändert: 02.03.2011 11:26

12/16

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML

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.

Zuletzt geändert: 02.03.2011 11:26

13/16

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML

Abb. 4–3 Screenshot zur Modellierung von Szenarien in einem Sequenzdiagramm

4.3 Erweiterung des Profils Im Folgenden wird beschrieben, wie das SysML Scenario Modeling Profile 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-Datei 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 zu. 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.

Zuletzt geändert: 02.03.2011 11:26

14/16

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML

5 Zusammenfassung 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 SzenarioProfils 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. Zukünftige Arbeiten zu diesem Thema werden sich mit der Erweiterung dieses Profils 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.

Zuletzt geändert: 02.03.2011 11:26

15/16

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML

6 Literaturverzeichnis [AvTe11]

[DaSiLa10]

[FrMoSt09] [LaGaSiTe10]

[LaSiStTe09]

[OMG10a] [OMG10b0]

[Pohl10] [SiStLa10]

[SiTePo10]

[SiTePo11]

[Sparx09] [Sparx10]

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 Daun, Marian; Sikora, Ernst; Lauenroth, Kim. Stand der Praxis im modellbasierten Requirements Engineering. SPES 2020 Deliverable D2.1.A, 2010. Friedenthal, Sanford; Moore, Alan; Steiner, Rick. A Practical Guide to SysML. Morgan Kaufman & OMG, 2009. 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 des ZP-AP2, Version 1.0 vom 16.07.2010. Lauenroth, Kim; Sikora, Ernst; Stallbaum, Heiko; Tenbergen, Bastian. Initialer modellbasierter Requirements Engineering Ansatz für Embedded Systems. SPES 2020 Teilergebnis des ZP-AP2, Version 0.9 vom 18.09.2009. Object Management Group: UML Superstructure Version 2.3, OMG formal/10-05-05 http://www.omg.org/spec/UML/2.3/ (2010) Object Management Group. OMG Systems Modeling Language (OMG SysML) Language Specification v1.2. OMG Document Number: formal/2010-06-02. 2010. Pohl, Klaus. Requirements Engineering – Foundations, Principles, Techniques. Springer, 2010. Sikora, Ernst; Stallbaum, Heiko, Lauenroth, Kim. Anforderungen an den zu entwickelnden Ansatz für modellbasiertes Requirements Engineering. SPES 2020 Teilergebnis des ZP-AP2, Version 1.0 vom 01.03.2010. Sikora, E., Tenbergen, B., Pohl, K.: Modellbasiertes Requirements Engineering - Eine Situationsanalyse zum Stand der Praxis. Softwaretechnik Trends 30(1) (2010) Sikora, E.; Tenbergen, B.; Pohl, K.: Requirements Engineering for Embedded Systems: - An Investigation of Industry Needs . To appear in Proceedings of the 17th International Working Conference on Requirements Engineering: Foundations of Software Quality REFSQ (2011) SparxSystems. Enterprise Architect User Guide. 2009. SparxSystems. Enterprise Architect Software Developers’ Kit. 2010.

Zuletzt geändert: 02.03.2011 11:26

16/16

Anhang D – ZP-AP2 Teilergebnis: SysML-Profil und MDGPlug-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

Projektbezeichnung

SPES 2020

Verantwortlich

Bastian Tenbergen (Universität Duisburg-Essen)

QS-Verantwortlich

Jörg Holtmann (UPB)

Erstellt am

01.03.2011

Zuletzt geändert

14.04.2011 08:37 Vertraulich für Partner: ; ; …

Freigabestatus

Projektöffentlich X Bearbeitungszustand

Öffentlich in Bearbeitung vorgelegt

X

fertig gestellt

Weitere Produktinformationen Erzeugung

Sebastian Gabrisch (SG), Bastian Tenbergen (BT)

Mitwirkend

Marian Daun (MD), Thorsten Weyer (TW)

Änderungsverzeichnis Änderung

Geänderte Kapitel

Beschreibung der Änderung

Autor

Zustand

Nr.

Datum

Version

1

01.03.11

0.1

Alle

Initiale Produkterstellung

BT

In Bearbeitung

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 REAnsatz [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.

Zuletzt geändert: 14.04.2011 08:37

3/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML

Inhalt 1

2

3

4

Einordnung und Kurzbeschreibung ..................................................................... 5 1.1

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

1.2

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

1.3

Überblick ....................................................................................................... 6

Einführung zur Modellierung lösungsorientierter Anforderungen und SysML ...... 7 2.1

Modellierung von lösungsorientierten Anforderungen ................................... 7

2.2

UML/SysML ................................................................................................... 7

2.3

Hinweise zur Implementierung des SysML-Profils mit EA ............................. 8

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

Verwendung des MDG-Plug-Ins ........................................................................ 13 4.1

Installation der MDG-Technologie ............................................................... 13

4.2

Verwendung des Profils ............................................................................... 13

4.3

Erweiterung des Profils ................................................................................ 15

5

Zusammenfassung ............................................................................................ 16

6

Literaturverzeichnis ........................................................................................... 17

Zuletzt geändert: 14.04.2011 08:37

4/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML

1 Einordnung und Kurzbeschreibung In diesem Abschnitt wird eine kurze Einordnung in den Projektkontext beschrieben und ein Überblick über den Dokumenteninhalt sowie den vorhergehenden Arbeiten gegeben.

1.1 Motivation und Einordnung Das vorliegende Ergebnisdokument beschreibt das Enterprise Architect Plug-In „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).

1.2 Management Summary 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], [DaSiLa10], [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 Gewinnungsund 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 ausZuletzt geändert: 14.04.2011 08:37

5/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML 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]).

1.3 Überblick Im folgenden Abschnitt 2 wird eine kurze Einführung zur Modellierung lösungsorientierter Anforderungen sowie zur UML/SysML gegeben. In Abschnitt 3 wird das EAPlug-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.

Zuletzt geändert: 14.04.2011 08:37

6/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML

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 Zuletzt geändert: 14.04.2011 08:37

7/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML 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]).

2.3 Hinweise zur Implementierung des SysML-Profils mit EA 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-OrientedRequirements“ 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.

Zuletzt geändert: 14.04.2011 08:37

8/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML

Abb. 2–1 Definition des SysML-Profils aus importierten Konzepten

Zuletzt geändert: 14.04.2011 08:37

9/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML

3 Beschreibung des Plug-Ins für lösungsorientierter Anforderungen in SysML In diesem Abschnitt wird das Enterprise Architect Plug-In beschrieben, in dem das 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 SysMLMetamodells 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 SolutionOriented 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 benutZuletzt geändert: 14.04.2011 08:37

10/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML 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 geZuletzt geändert: 14.04.2011 08:37

11/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML ö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

Zuletzt geändert: 14.04.2011 08:37

12/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML

4 Verwendung des MDG-Plug-Ins 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.

4.1 Installation der MDG-Technologie Dieses MDG-Plug-In befindet sich zusammen mit der Enterprise Architect Projektdatei 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. 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. 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 EnterpriseArchitect-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 SysML Solution-Oriented Modeling-Plug-In aufgeführt werden. Weitere Möglichkeiten zur Einbindung von MDG-Plug-Ins in Enterprise Architect sind in [Sparx10] erläutert.

4.2 Verwendung des Profils Im Folgenden wird beschrieben, wie das SysML Solution-Oriented Modeling-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 verwenden Sie „Dynamic“ als Sicht auf die Modelle in diesem Paket, wie in Abb. 4–1 dargestellt. Klicken Sie anschließend auf OK.

Zuletzt geändert: 14.04.2011 08:37

13/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML

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 MDGTechnologie „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.

Zuletzt geändert: 14.04.2011 08:37

14/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML

Abb. 4–3

Screenshot zur Modellierung von lösungsorientierten Anforderungen in einem Aktivitätsdiagramm

4.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-Datei 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 zu. 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.

Zuletzt geändert: 14.04.2011 08:37

15/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML

5 Zusammenfassung In diesem Dokument wurde das SysML Solution-Oriented Modeling Profile für Enterprise Architect vorgestellt. Bei dem SysML-Profil handelt es sich um eine MDGTechnologie, 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. Zukünftige Arbeiten zu diesem Thema werden sich mit der Erweiterung dieses Profils 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.

Zuletzt geändert: 14.04.2011 08:37

16/17

SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von lösungsorientierten Anforderungen auf Basis von SysML

6 Literaturverzeichnis [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.

[DaSiLa10]

Daun, Marian; Sikora, Ernst; Lauenroth, Kim. Stand der Praxis im modellbasierten Requirements Engineering. SPES 2020 Deliverable D2.1.A, 2010.

[Davis93]

Davis, A. M.: Software Requirements – Objects, Functions, and States. 2nd Edition. Prentice Hall (1993)

[FrMoSt09]

Friedenthal, Sanford; Moore, Alan; Steiner, Rick. A Practical Guide to SysML. Morgan Kaufman & OMG, 2009.

[LaGaSiTe10]

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.

[LaSiStTe09]

Lauenroth, Kim; Sikora, Ernst; Stallbaum, Heiko; Tenbergen, Bastian. Initialer modellbasierter Requirements Engineering Ansatz für Embedded Systems. SPES 2020 Teilergebnis, Version 0.9 vom 18.09.2009.

[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)

[Pohl10]

Pohl, Klaus. Requirements Engineering – Foundations, Principles, Techniques. Springer, 2010.

[SiStLa10]

Sikora, Ernst; Stallbaum, Heiko, Lauenroth, Kim. Anforderungen an den zu entwickelnden Ansatz für modellbasiertes Requirements 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)

[SiTePo11]

Sikora, E.; Tenbergen, B.; Pohl, K.: Requirements Engineering for Embedded Systems: - An Investigation of Industry Needs . To appear in Proceedings of the 17th International Working Conference on Requirements Engineering: Foundations of Software Quality REFSQ (2011)

[Sparx09]

SparxSystems. Enterprise Architect User Guide. 2009.

[Sparx10]

SparxSystems. Enterprise Architect Software Developers’ Kit. 2010.

Zuletzt geändert: 14.04.2011 08:37

17/17