- Deliverable D2.4B: Leitfaden und Projektschablonenbeschreibung für die modellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs-
Version: 1.0
Projektbezeichnung
SPES 2020
Verantwortlich
Bastian Tenbergen (Universität Duisburg-Essen)
QS-Verantwortlich
An Fallstudien beteiligte Projektpartner
Erstellt am
18.04.2011
Zuletzt geändert
29.04.2011 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), Philipp Bohn (PB)
Mitwirkend
Thorsten Weyer (TW), Nadezhda Avramova (NA)
Änderungsverzeichnis Änderung
Geänderte Kapitel
Beschreibung der Änderung
Autor
Zustand
Nr.
Datum
Version
1
18.04.11
0.1
Alle
Initiale Produkterstellung
BT, MD
In Bearbeitung
2
18.04.11
0.2
Alle
Inhaltliche Vervollständigung
PB
In Bearbeitung
3
20.04.11
0.3
Alle
Inhaltliche Vervollständigung
PB
In Bearbeitung
4
29.04.11
0.4
Alle
Internes Review und Überarbeitung
BT
In Bearbeitung
5
29.04.11
0.5
2, 3
Kleinere inhaltliche Korrektur
BT
In Bearbeitung
6
29.04.11
0.6
Alle
Internes Review
NA, TW
In Bearbeitung
7
29.04.11
1.0
Alle
Finalisierung
BT
Fertig gestellt
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
Kurzfassung Die Universität Duisburg-Essen hat im Rahmen der Arbeiten im ZP-AP2 einen initialen modellbasierten Requirements-Engineering-Ansatz vorgeschlagen (siehe [LaSiStTe09]). Dieser stellt zusammen mit der Feststellung des Standes der Praxis im modellbasierten Requirements Engineering (siehe [DaSiLa10], sowie [LaGaSiTe10 und [SiTePo11]) und der Sammlung eines Anforderungskataloges an einen modellbasierten RE-Ansatz (siehe [SiStLa10]) den Grundstein der Arbeiten im ZP-AP2 dar. Die Anwendung des Ansatzes wurde über den Projektverlauf anhand von Fallbeispielen evaluiert. Parallel dazu wurden mehrere Profile entwickelt, die die Anwendung des Ansatzes im Hinblick auf die zu modellierenden Artefakttypen unterstützen. Das vorliegende Dokument und die damit einhergehende Projektschablone stellen nicht nur eine Unterstützung bei der strukturierten Ausarbeitung dieser Artefakte bereit, sondern erleichtert die strukturierte Ableitung von Abstraktionsebenen während der Entwicklung.
Zuletzt geändert: 29.04.2011, 14:45
3/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
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 Änderungen des Artefaktmodells ........................................................................ 6 2.1 Der Artefakttyp „Überblicksdiagramm“ ......................................................... 6 2.2 Der Artefakttyp „Umwelt“ .............................................................................. 6 2.3 Lösungsorientierte Anforderungen: Datenperspektive ................................. 7 Aufbau der Projektschablone .............................................................................. 8 3.1 Überblicksdiagramm über die Dekompositionshierarchie ............................. 8 3.2 Pakete auf der ersten Ebene der Projektschablone ................................... 10 3.3 Pakete auf der zweiten Ebene ................................................................... 12 3.4 Pakete auf der dritten Ebene ...................................................................... 13 Kompakte Darstellung des RE-Ansatzes........................................................... 21 4.1 Anwendung in einer etablierten und verstandenen Domäne ...................... 21 4.2 Typische Vorgehensweisein einer etablierten und verstandenen Domäne 21 4.3 Anwendung zur Entwicklung eines innovativen Systems ........................... 22 4.4 Typische Vorgehensweise zur Entwicklung eines innovativen Systems .... 22 Zusammenfassung ............................................................................................ 24 Literaturverzeichnis ........................................................................................... 25
Zuletzt geändert: 29.04.2011, 14:45
4/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
1 Einordnung und Kurzbeschreibung Dieser Abschnitt fasst kurz den Inhalt dieses Dokumentes zusammen und gibt Aufschluss über den Zweck des Dokumentes bezüglich der Vorangegangenen Arbeiten im ZP-AP2.
1.1 Motivation und Einordnung Das vorliegende Ergebnisdokument beschreibt die Enterprise Architect Projektschablone, die die Anwendung des modellbasierten RE-Ansatzes , der im Rahmen von ZPAP2 entwickelt wurde ([LaSiStTe09]), unterstützt. Die Projektschablone bildet das Artefakt- und Abstraktionsebenenmodell des RE-Ansatzes auf die EA-Paketstruktur ab und wird in diesem Dokument erläutert. Die Notwendigkeit zur Entwicklung einer Projektschablone wurde im Rahmen der Anwendung des initialen modellbasierten RE-Ansatzes anhand der Fallbeispiele „Motorsteuerung“ und „AV-Klimaanlage“ ersichtlich. Der Zweck dieser Schablone ist, den Anwender des Ansatzes strukturiert an die zu modellierenden Artefakttypen heranzuführen und ihm bei der Entwicklung der Artefakte auf verschiedenen Abstraktionsstufen zu helfen. Das vorliegende Dokument ist das Vierte in einer Reihe von Dokumenten, die die zur Unterstützung der Anwendung des Ansatzes bereitgestellt wurden; die vorangegangenen Dokumente beschreiben die Implementierung von Profilen für die einzelnen Artefakttypen des RE-Ansatzes.
1.2 Management Summary Die Universität Duisburg-Essen hat im Rahmen der Arbeiten im ZP-AP2 einen initialen modellbasierten Requirements-Engineering-Ansatz vorgeschlagen (siehe [LaSiStTe09]). Dieser stellt zusammen mit der Feststellung des Standes der Praxis im modellbasierten Requirements Engineering (siehe [DaSiLa10], sowie [LaGaSiTe10 und [SiTePo11]) und der Sammlung eines Anforderungskataloges an einen modellbasierten RE-Ansatz (siehe [SiStLa10]) den Grundstein der Arbeiten im ZP-AP2 dar. Die Anwendung des Ansatzes wurde über den Projektverlauf anhand von Fallbeispielen evaluiert. Parallel dazu wurden mehrere Profile entwickelt, die die Anwendung des Ansatzes im Hinblick auf die zu modellierenden Artefakttypen unterstützen. Das vorliegende Dokument und die damit einhergehende Projektschablone stellen nicht nur eine Unterstützung bei der strukturierten Ausarbeitung dieser Artefakte bereit, sondern erleichtert die strukturierte Ableitung von Abstraktionsebenen während der Entwicklung.
1.3 Überblick Im folgenden Abschnitt 2 werden die Neuerungen des RE-Ansatzes, die sich in der Projektschablone wiederfinden, erläutert. Abschnitt 3 erläutert ausführlich den Aufbau der Projektschablone und zeigt die Verwendung der Schablone anhand eines durchgängigen Beispiels. Abschnitt 4 erläutert die Anwendung des RE-Ansatzes unter Zuhilfenahme der in Abschnitt 3 erläuterten Projektschablone anhand zweier typischer Entwicklungsszenarien. Abschnitt 5 fasst dieses Dokument zusammen.
Zuletzt geändert: 29.04.2011, 14:45
5/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
2 Änderungen des Artefaktmodells In diesem Abschnitt werden die Neuerungen des Artefaktmodells beschrieben, die in der Projektschablone aufgenommen wurden. Dabei handelt es sich um Zusätze bzw. Verkürzungen des ursprünglichen Artefaktmodells des initialen RE-Ansatzes, die sich im Laufe der Bearbeitung der Fallstudien als sinnvoll herausgestellt haben, um die Durchgängigkeit des RE-Ansatzes zu gewährleisten. Im Folgenden werden diese Neuerungen kurz erläutert.
2.1 Der Artefakttyp „Überblicksdiagramm“ Als eine Erweiterung des initialen RE-Ansatzes bietet das Überblicksdiagramm eine integrierte Sicht auf die im RE-Prozess gefallenen Architekturentscheidungen. Die Sicht basiert auf der Notwendigkeit, den Systemzusammenhang zu überblicken und die Sachverhalte orthogonal zum Rest des Projektes darstellen zu können.
2.1.1 Zweck des Artefakttypen „Überblicksdiagramm“ Während des Co-Designs von Anforderungsartefakten und Architekturartefakten kommt es im RE-Prozess zu einer Reihe von Architekturentscheidungen, die Auswirkungen auf den RE-Prozess haben. Konkret bedeutet dies, dass ein System auf einer beliebigen Abstraktionsebene in Sub-Systeme unterteilt wird, also die Architekturentscheidung getroffen wird, das System in eine bestimmte Menge von SubSystemen aufzuteilen. Dieser Architekturentwurf wird zur Eingabe für den REProzess auf der nächsten Abstraktionsebene. Alle im Architekturentwurf spezifizierten Sub-Systeme werden zum Gegenstand der Spezifikation auf der nächsten Abstraktionsebene. So entsteht eine Baumstruktur von Systemen, die jeweils SubSysteme aggregieren. Der initiale RE-Ansatz beinhaltet allerdings keine Möglichkeit, einen Überblick über alle bereits getroffenen Architekturentscheidungen zu bekommen und so die gesamte System- bzw. Dekompositionshierarchie zu betrachten. Der neue Artefakttyp „Überblicksdiagramm“ stellt eine solche Baumstruktur der Dekompositionshierarchie zur Verfügung.
2.1.2 Konkrete Darstellung in der Projektschablone Der Artefakttyp „Überblicksdiagramm“ vereint die verschiedenen Architekturartefakte des Projektes und setzt sie in einer hierarchischen Struktur in Beziehung. Der Aufbau des Diagramms ist äquivalent zum Aufbau der Paketstruktur im Projekt-Browser des Modellierungswergzeuges. Das Überblicksdiagramm wird keiner der Abstraktionsebenen zugeordnet, sondern ist orthogonal zu diesen. Daher ist dieser Artefakttyp in einem eigenen Paket in der Projektschablone dargestellt und somit der Gesamtsystemebene als „nulltes“ Paket vorangestellt. In der Projektschablone wird das Artefakt in dem Paket „0. Architecture Overview“ abgelegt. Details zur konkreten Darstellung können Abschnitt 3.1 entnommen werden.
2.2 Der Artefakttyp „Umwelt“ Im Artefakttypen „Umwelt“ wird das System in Bezug auf seinen Kontext betrachtet. Dazu wird das System als Black-Box betrachtet, sodass die Interaktion des Systems mit seiner Umwelt Gegenstand der Modellierung ist. In der Projektschablone wird das Artefakt in dem Paket „Environment“ abgelegt.
Zuletzt geändert: 29.04.2011, 14:45
6/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
2.2.1 Zweck des Artefakttypen „Umwelt“ Das System, welches Gegenstand der Spezifikation auf einer bestimmten Abstraktionsebene ist, bekommt Eingaben aus der Umwelt, bzw. liefert Ausgaben an die Umwelt. Ein- bzw. Ausgaben können Datenflüsse von externen Systemen, Benutzerinteraktionen oder auch Ereignisse in der Umwelt sein. Externe Systeme bzw. Benutzer befinden sich in der Umwelt des Systems (dem sogenannten „Kontext“, siehe [Pohl10]) und werden als „Kontextentitäten“ bezeichnet. Es ist zu beachten, dass Kontextentitäten auch Sub-Systeme auf der gleichen oder anderen Abstraktionsstufen sein können, die zum gleichen Obersystem gehören. Kontextentitäten kommunizieren mit dem System über Schnittstellen und erwarten, abhängig vom Zweck des Systems, eine gewisse Ausgabe, ebenfalls über eine Schnittstelle. Um die Anforderungsartefakte eines Systems, insbesondere die Ziele und die Funktionen eines Systems, spezifizieren zu können, ist es somit erforderlich, ein Verständnis über die Rolle des Systems in seinem Kontext zu erhalten und die Schnittstellen zum Kontext zu definieren. Das Artefaktmodell des initialen REAnsatzes sieht kein Artefakt vor, welches diesen Zweck erfüllen kann, sodass ein separater Artefakttyp notwendig ist.
2.2.2 Konkrete Darstellung in der Projektschablone Da der Artefakttyp „Umwelt“ von den Interna des Systems abstrahiert und das System als Black-Box betrachtet, ist dieser Artefakttyp die Eingabe für den RE-Prozess des Systems und wird dem Artefakttyp „Zielmodell“ (siehe [LaSiStTe09], Abschnitt 1.2.1) vorangestellt. Das Umweltmodell kann somit als Vorlage für die Spezifikation der Ziele dienen, die in den Zielmodellen spezifiziert werden. Details zur konkreten Darstellung können Abschnitt 3.4.1 entnommen werden.
2.3 Lösungsorientierte Anforderungen: Datenperspektive Für die Entwicklung von eingebetteten Systemen gilt, dass die separate Behandlung von Datendiagrammen nicht bei jeder Art von Systemen erforderlich ist. Insbesondere bei der Spezifizierung von Sub-Systemen auf sehr tiefen Abstraktionsebenen werden Datenabhängigkeiten in Funktions- und Architekturmodellen anstelle von dedizierten Datenmodellen dargestellt, da die Datenabhängigkeiten über die Zugehörigkeit von Schnittstellen an Funktionen und Systemen eindeutig spezifizierbar sind. Daher wird die explizite Betrachtung der Datenperspektive in der aktualisierten Fassung der Schablone nicht explizit aufgeführt, kann aber bei Bedarf spezifiziert werden (siehe Abschnitt 3.4.3).
Zuletzt geändert: 29.04.2011, 14:45
7/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
3 Aufbau der Projektschablone Ein Projekt unter Verwendung des RE-Ansatzes und der Enterprise Architect Projektschablone wird über mehrere Paketebenen gegliedert, da Enterprise Architect die tabellenhafte Struktur des Artefakt- und Abstrakionsstufenmodells des intitalen REAnsatzes nicht nativ abbilden kann. Im Folgenden wird die hierarchische Anordnung der Pakete in der Enterprise Architect Projektschablone erläutert. Für die gesamte Beschreibung der Schablone ist zu beachten, dass die genutzte Strukturtiefe, wie beispielsweise die Anzahl der Abstraktionsebenen (siehe Abschnitt 3.2) oder die Anzahl der Pakete für spezifizierte Sub-Systeme (siehe Abschnitt 3.3), abhängig von dem Projekt ist, in dem sie eingesetzt wird. Im Folgenden wird daher der grundsätzliche Aufbau der Projektschablone beschrieben; die Struktur jeder Subsystemebene ist analog zur ersten Sub-Systemebene. Für das leichtere Verständnis wird in diesem Kapitel ein durchgängiges Beispiel verwendet, um die Struktur der Projektschablone und deren Verwendung zu erläutern. Bei diesem Beispiel handelt es sich um ein im Rahmen der Arbeiten zur Integration der Ansätze aus den einzelnen SPES-Arbeitspaketen entstandenes Fallbeispiel „Zylinderkopffertigungsanlage“ aus dem Anwendungsgebiet Automatisierungstechnik.
3.1 Überblicksdiagramm über die Dekompositionshierarchie Als „nulltest“ Paket beinhaltet die Projektschablone ein zu den Abstraktionsebenen orthogonales Paket, welches den Artefakttypen „Überblicksdiagramm“ beinhaltet (siehe Abb. 3-1 und Abb. 3-2). Bei dem Überblicksdiagramm handelt es sich um einen dem RE-Ansatz hinzugefügten Artefakttypen, wie bereits in Abschnitt 2.1 dargestellt wurde. Das Überblicksdiagramm beschreibt die Dekompositionshierarchie des Projektes orthogonal zu den definierten Abstraktionsebenen. Daher ist es den Paketen für die Abstraktionsebenen (siehe Abschnitt 3.2) vorgelagert und somit das nullte Paket. Es erfüllt den Zweck, einen Überblick über die Architekturentscheidungen zu aufzuzeigen, die im RE-Prozess gefallen sind. Abb. 3-2 zeigt das Überblicksdiagramm der Dekompositionshierarchie und somit die Gesamtarchitektur der Zylinderkopffertigungsanlage. Es verdeutlicht die Analogie zwischen Diagramm und den im Projekt verwendeten Abstrakionsebenen, sowie der Dekomposition der einzelnen Systeme bzw. Sub-Systeme. Ausgehend von dem Gesamtsystem auf der Gesamtsystemebene gibt es drei weitere Abstraktionsebenen, auf denen die Architektur des Systems verfeinert wird.
Zuletzt geändert: 29.04.2011, 14:45
8/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs Dieses übergeordnete Paket beinhaltet eine Übersicht aller im Architekturentwurf festgelegten Komponenten und Subsysteme. Dies ist eine Erweiterung des initialen Ansatzes und erleichtert den Überblick über das Projekt.
Abb. 3-1 Darstellung des Überblicksdiagramm in der Projektschablone
Abb. 3-2 Architekturüberblick am Beispiel „Zylinderkopffertigungsanlage“
Zuletzt geändert: 29.04.2011, 14:45
9/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
3.2 Pakete auf der ersten Ebene der Projektschablone Die auf der ersten Paketebene der Schablone dargestellten Enterprise Architect Pakete repräsentieren die Abstraktionsebenen des initialen modellbasierten Requirements-Engineering-Ansatzes (siehe Abb. 3-3). Das Abstraktionsebenenmodell des intialen, modellbasierten RE-Ansatzes wurde in [LaSiStTe09], Abschnitt 2 ausführlich erläutert. Die Bezeichnung der Abstraktionsebenen ist beliebig und dem Projekt spezifisch vorzunehmen. Das erste Paket, welches eine Abstraktionsebene repräsentiert ist die Gesamtsystemebene. Dieses ist dem Paket des Architekturüberblicks (vgl. Abb. 3-1 und Abb. 3-3) nachgelagert, da das Überblicksdiagramm orthogonal zu allen Ebenen ist und als „nulltest“ Paket definiert ist (vgl. Abschnitt 2.1). In Abhängigkeit von der Komplexität des Projektes können beliebig viele Abstraktionsebenen für Sub-Systeme angelegt werden, die jeweils alle Sub-Systeme der Systeme auf der nächst-höheren Abstraktionsebene beinhalten. Die tiefste Ebene ist stets die „Komponentenebene“. Die Besonderheiten, die bei der Definition von Abstraktionsebenen zu beachten sind, werden im Folgenden kurz erläutert. Die Pakete auf oberster Ebene entsprechen den Abstraktionsebenen des initialen Ansatzes. Ziele
Szenarien
Lösungsorientierte Anforderungen
Architektur
L1 Systemebene R1 RN
Systemziele
Systemszenarien
Lösungsorientierte Systemanforderungen
Einbettung des Systems
L2 Komponentenebene R1.1 R1.M
Komponentenziele
Komponentenszenarien
Lösungsorientierte Komponentenanforderungen
(Logische) Systemarchitektur
L3 …
Prinzipiell sind beliebig viele Pakete bzw. Abstraktionsebenen möglich.
Abb. 3-3 Abbildung des Abstraktionsstufenmodells in der Projektschablone
Zuletzt geändert: 29.04.2011, 14:45
10/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
3.2.1 Die oberste Abstraktionsebene „Gesamtsystemebene“ Die „Gesamtsystemebene“ ist immer die oberste Ebene und wird in der Schablone durch das Paket „Gesamtsystemebene“ repräsentiert. Die Besonderheit dieses Paketes ist, dass es keine Sub-Pakete zur Beschreibung orthogonaler Systeme (siehe Abschnitt 3.3) aggregiert, da auf der obersten Abstraktionsebene immer nur ein System, das Gesamtsystem, spezifiziert wird. Daher sind auf dieser Abstraktionsebene die Artefakttypen bereits auf der zweiten, anstelle der dritten Paketebene (siehe Abschnitt 3.4) zu finden, wie in Abb. 3-4 zu sehen ist.
Abb. 3-4 Unterpakete für Artefakttypen auf der Gesamtsystemebene
3.2.2 Die unterste Abstraktionsebene „Komponentenebene“ Die unterste Ebene besteht ausschließlich aus Komponenten, daher der Bezeichnung „Komponentenebene“. Die besitzt die Sub-Pakete zur Beschreibung der orthogonalen Systeme (siehe Abschnitt 3.3), in denen wiederum die Artefakttypen im jeweiligen Paket abgelegt sind (siehe Abschnitt 3.4). Da es sich bei der „Komponentenebene“ um die unterste Ebene handelt (d. h. Komponenten sind atomar), gibt es keine Sub-Komponenten, die eine Verfeinerung der Komponenten darstellen. Das hat zur Folge, dass es keine Architekturartefakte (siehe Abschnitt 3.4.4) für Komponenten gibt, sodass das Sub-Paket „Architektur“ leer bleibt bzw. weggelassen werden kann. Ein Beispiel für die Komponentenebene ist in Abb. 3-5 dargestellt. Eine Besonderheit des Beispiels der Zylinderkopffertigungsanlage ist, dass es zwei Komponentenebenen gibt. Das liegt daran, dass auf Komponentenebene 1 außer Komponenten noch ein Sub-System, welches selber aus Komponenten besteht, spezifiziert worden ist. Die Komponenten dieses Sub-Systems werden auf Komponentenebene 2 spezifiziert. Somit handelt es sich bei Komponentenebene 2 um die eigentliche Komponentenebene gemäß der o.g. Erläuterung, während es sich bei Komponentenebene 1 lediglich um eine Sub-Systemebene handelt, auf der neben einem Sub-System auch Komponenten definiert worden sind.
Zuletzt geändert: 29.04.2011, 14:45
11/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
Abb. 3-5 Pakete der Komponentenebene
3.2.3 Die restlichen Abstraktionsebenen Zwischen der obersten und der untersten Abstraktionsebene kann eine beliebige Menge von System-, bzw. Sub-Systemebenen spezifiziert werden. Diese werden ebenfalls als Enterprise Architect Pakete auf der ersten Paketebene dargestellt. Die Anzahl der Ebenen ist projektspezifisch und kann daher variieren. Der Aufbau jeder dieser Ebenen ist jeweils gleich: Sie bestehen aus Paketen für jedes auf dieser Ebene spezifizierte Sub-System (siehe Abschnitt 3.3), die wiederrum aus Paketen für die Artefakttypen bestehen (siehe Abschnitt 3.4).
3.3 Pakete auf der zweiten Ebene Auf der zweiten Paketebene werden Sub-Systeme spezifiziert, die Ergebnis des Architekturentwurfes auf der nächst-höheren Abstraktionsebene sind. Die Anzahl und Bezeichnungen der Pakete für die Sub-Systeme, also der Pakete auf der zweiten Paketebene, sind projektspezifisch und werden aus der Architektur des Systems auf der übergeordneten Abstraktionsebene abgeleitet, wie in Abb. 3-6 dargestellt ist. Eine Änderung im Architekturentwurf eines Systems auf einer Abstraktionsebene wirkt sich ebenfalls auf das Überblicksdiagramm der Dekompositionshierarchie aus, wie in Abb. 3-7 dargestellt.
Zuletzt geändert: 29.04.2011, 14:45
12/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs Die auf der obersten Ebene („VehicleLevel“) im Architekturentwurf festgelegten Systeme werden zu weiteren Paketen auf der nächsten Abstraktionsebe.
Abb. 3-6 Abbildung orthogonaler Sub-Systeme auf der zweiten Abstraktionsebene Änderungen im Architekturentwurf eines Systems auf einer Abstraktionsebene wirken sich auch auf das Überblicksdiagramm der Dekompositionshierarchie aus.
Abb. 3-7 Auswirking des Architekturentwurfes auf das Überblicksdiagramm
3.4 Pakete auf der dritten Ebene In den Paketen der dritten Ebene werden die Artefakttypen des jeweiligen Systems spezifiziert. Die Artefakttypen wurden bereits in [LaSiStTe09], Abschnitt 1.2 ausführlich erläutert. Die verschiedenen Artefakttypen sind stets auf die folgenden vier Pakete aufgeteilt: „Umwelt“, „Ziele / Szenarien“, „Funktionen / Zustände“ und „Architektur“. Abb. 3-8 stellt die Aufteilung der Artefakttypen des initialen RE-Ansatzes in Enterprise Architect Pakete in der Projektschablone dar. In Abb. 3-8 wird deutlich, dass ursprüngliche Artefakttypen des intialen RE-Ansatzes zu gemeinsamen Paketen zusammengefasst worden sind; die Zusammenfassung von Artefakttypen zu Paketen erfolgte beim Entwurf der Projektschablone anhand des Abstraktionsgerades der Artefakttypen (siehe [Pohl10], Seite 217, Fig. 13-1). Ein weiteres Paket auf der dritten Ebene ist für den neuen Artefakttypen „Umwelt“ vorgesehen, wie in Abschnitt 2.2 beschrieben wurde, das in Abb. 3-9 dargestellt ist. Da sich Ziele häufig aus der InterakZuletzt geändert: 29.04.2011, 14:45
13/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs tion des Systems mit seiner Umwelt ergeben, ist der Artefakttyp „Umwelt“ den Zielen vorgelagert. Anforderungsartefakte werden in Paketen zusammengefasst. Diese gibt es für jedes im Architekturentwurf festgelegte System. Der Architekturentwurf legt die Dekomposition des aktuellen (Sub-)Systems fest. Die Entwurfsentscheidungen haben einen Einfluss auf die Paketstruktur der nächsten Ebenen (siehe Abb. 3-2).
Ziele
Szenarien
Lösungsorientierte Anforderungen
Architektur
L1 Systemebene R1 RN
Systemziele
Systemszenarien
Lösungsorientierte Systemanforderungen
Einbettung des Systems
L2 Komponentenebene R1.1 R1.M
Komponentenziele
Komponentenszenarien
Lösungsorientierte Komponentenanforderungen
(Logische) Systemarchitektur
L3 …
Abb. 3-8 Abbildung des Artefakttypenmodells in der Projektschablone Eine Neuerung zum initialen Ansatz ist der Artefakttyp „Umwelt“. In den Umweltmodellen werden externe Einflüße auf das System (beispielsweise durch externe Akteure wie dem Fahrer oder andere Systeme) modelliert. Da sich Ziele häufig aus der Interaktion des Systems mit seiner Umwelt ergeben ist dieser Artefakttyp den Zielen vorgelagert.
Abb. 3-9 Abbildung des Artefakttypen „Umwelt“ in der Projektschablone
Im Folgenden werden die vier Artefakttypen, die Bestandteil jedes SubSystempaketes sind, beschrieben und anhand des Beispiels der Zylinderkopffertigungsanlage verdeutlicht.
Zuletzt geändert: 29.04.2011, 14:45
14/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
3.4.1 Der Artefakttyp „Umwelt“ Der Artefakttyp „Umwelt“ wurde bereits in Abschnitt 2.2 erläutert. Zur Modellierung von Umweltmodellen werden im RE-Ansatz SysML-Block-Definition-Diagramme verwendet, aber auch UML Klassendiagramme oder sonstige Strukturmodelle können verwendet werden. Ein Profil zur Modellierung dieses Artefakttyps wird in [TeGaDaWe11b] erläutert und bereitgestellt. In Abb. 3-10 ist das Umweltmodell auf der Abstraktionsebene „Gesamtsystem“ für das Fallbeispiel „Zylinderkopffertigungsanlage“ dargestellt. An diesem Beispiel wird illustriert, dass das betrachtete System unabhängig von seinen Interna betrachtet wird und der Fokus auf den Schnittstellen des Systems zu seinen Kontextentitäten liegt. Als Kontextentitäten wird die Umwelt, ein Benutzer (stellvertretend für alle Benutzer des Systems), sowie vier externe Systeme betrachtet.
Abb. 3-10 Umweltdiagramm am Beispiel „Zylinderkopffertigungsanlage“
Zuletzt geändert: 29.04.2011, 14:45
15/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
3.4.2 Die Artefakttypen „Ziele“ und „Szenarien“ Ziel- und Szenariomodelle werden zusammen in einem Paket gebündelt, da diese im Hinblick auf die Menge an Lösungsdetails, die sie enthalten, einen ähnlichen Abstraktionsgrad haben (siehe [Pohl10], Seite 217, Fig. 13-1). Zur Zielmodellierung können KAOS-Zielmodelle verwendet werden, für die in [TeDaSiSt10] ein SysML-Profil zur Verfügung gestellt wird. Die in einem Zielmodell definierten Ziele werden in Szenariomodellen verfeinert. Als Szenariomodelle werden Use-Case-Diagramme und Sequenzdiagramme (siehe [TeAvDaWe11a]) verwendet. Die Use-Case-Diagramme fassen eine Menge von Sequenzdiagrammen zusammen. Sequenzdiagramme beschreiben exemplarisch Szenarioabläufe, d.h. Interaktionen der Kontextentitäten mit dem System. Die Sequenzdiagramme werden zu dem Zweck der Zielerfüllung erstellt. Abb. 3-11, Abb. 3-12 und Abb. 3-13 zeigen die Zielmodelle und Szenariomodelle auf der Abstraktionsebene „Gesamtsystem“ am Beispiel der Zylinderkopffertigungsanlage. Die Durchgängigkeit des Ansatzes wird unter Anderem durch Überschneidungen mit dem Umweltdiagramm bzgl. der Kontextentitäten deutlich: Die Kontextentitäten des Umweltdiagrammes (siehe Abb. 3-9) werden als Akteure in Abb. 3-12 und als Sequenzen in Abb. 3-12 repräsentiert.
Abb. 3-11 KAOS-Zieldiagramm auf der Gesamtsystemebene der Zylinderkopffertigungsanlage
Abb. 3-12 Use-Case-Diagramm zur Szenariomodellierung auf der Gesamtsystemebene der Zylinderkopffertigungsanlage
Zuletzt geändert: 29.04.2011, 14:45
16/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
Abb. 3-13 Sequenzdiagramm zur Szenariomodellierung auf der Gesamtsystemebene der Zylinderkopffertigungsanlage
Zuletzt geändert: 29.04.2011, 14:45
17/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
3.4.3 Die Artefakttypen „Lösungsorientierte Anforderungen“ Als lösungsorientierte Anforderungen werden Datenmodelle, Funktionsmodelle und Verhaltensmodelle bezeichnet und in [LaSiStTe09] sowie [Pohl10] ausführlich beschrieben. Die Modelle lösungsorientierter Anforderungen werden in der Projektschablone in einem Paket gebündelt. Diese Bündelung ist damit begründet, dass die beiden Diagrammarten im Hinblick auf ihren Detailreichtum bzgl. der Lösung ähnlich abstrakt sind (siehe [Pohl10], Seite 217, Fig. 13-1). In diesem Paket werden vorrangig lösungsorientierte Anforderungen in den Perspektiven „Funktion“ und „Verhalten“ spezifiziert. Die Zustandsdiagramme werden auf Grundlage der zuvor erstellten Sequenzdiagramme entwickelt. Die Funktionsdiagramme werden parallel zu den Zustandsdiagrammen modelliert. Datenmodelle können bei Bedarf spezifiziert werden, wenn eine genauere Spezifikation der Datenabhändigkeiten notwendig wird, d.h. die Datenabhängigkeiten nicht aus den Schnittstellenspezifikationen der Funktions- und Architekturdiagramme heraus ersichtlich werden (siehe Abschnitt 2.3). Typischerweise werden zurModellierung lösungsorientierter Anforderungen SysML State Machine-Diagramme, SysML Aktivitätsdiagramme und SysML Blockdiagramme verwendet, wofür in [TeGaDaWe11b] ein Profil bereitgestellt wird. Abb. 3-14, Abb. 3-15 und Abb. 3-16 zeigen die Verhaltens-, Funktions- und Datenmodelle auf der Abstraktionsebene „Gesamtsystem“ am Beispiel der Zylinderkopffertigungsanlage. Die Zustände im Verhaltensdiagramm wurden aus den Sequenzdiagrammen auf der gleichen Abstraktionsebene abgeleitet und werden durch die Funktionen im Funktionsdiagramm genauer spezifiziert. Das Datenmodell spezifiziert die Datenabhängigkeiten, die aus dem Umweltmodell abgeleitet werden und im Funktionsmodell weiter verwendet werden.
Abb. 3-14 Zustandsmodell zur Modellierung einer lösungsorientierten Anforderung in der Verhaltensperspektive auf der Gesamtsystemebene der Zylinderkopffertigungsanlage
Zuletzt geändert: 29.04.2011, 14:45
18/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
Abb. 3-15 Funktionsmodell zur Modellierung einer lösungsorientierten Anforderung in der Funktionsperspektive auf der Gesamtsystemebene der Zylinderkopffertigungsanlage
Abb. 3-16 Datenmodell zur Modellierung einer lösungsorientierten Anforderung in der Datenperspektive auf der Gesamtsystemebene der Zylinderkopffertigungsanlage Zuletzt geändert: 29.04.2011, 14:45
19/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
3.4.4 Der Artefakttyp „Architektur“ In Architekturmodellen wird die wesentliche Struktur des Systems modelliert. Dabei werden Schnittstellen zu anderen, externen Systemen (siehe Abschnitt 3.4.1) verfeinert und die systeminterne Verwendung der eingehenden Daten durch interne Systeme spezifiziert. Somit beschreibt das Architekturmodell den inneren Aufbau des Systems und zeigt, in welcher hierarchischen Beziehung Systeme und Teilsysteme stehen und wie diese untereinander zur Kommunikation miteinander gekoppelt sind. Durch das Architekturdiagramm werden die zuvor erarbeiteten Funktionen auf die Sub-Systeme verteilt. Zur Modellierung eines Architekturartefakts können SysML Block-Diagramme (siehe [TeGaDaWe11b]) verwendet werden. Abb. 3-17 illustriert ein Architekturmodell auf der Gesamtsystemebene der Zylinderkopffertigungsanlage. Anhand des Beispiels ist zu erkennen, aus welchen SubSystemen das System besteht. Über die Schnittstellenbeschreibung und Assoziationen wird dargestellt, wie die Sub-Systeme untereinander in Verbindung stehen und wie diese die eingehenden Daten an den Schnittstellen auf der Gesamtsystemebene verwenden.
Abb. 3-17 Architekturmodell auf der Gesamtsystemebene der Zylinderkopffertigungsanlage
Zuletzt geändert: 29.04.2011, 14:45
20/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
4 Kompakte Darstellung des RE-Ansatzes Der in [LaSiStTe09] erläuterte initiale, modellbasierte Requirements-EngineeringAnsatz stellt einen Rahmen von essenziellen Konzepten zur Verfügung, die das Requirements Engineering für softwareintensive eingebettete Systeme prägen und unterstützen und die, abhängig von den Spezifika der jeweiligen Entwicklungsprozesse, und abhängig von der jeweiligen Anwendungsdomäne (z.B. Automotive, Avionic, Automatisierungstechnik), unterschiedlich eingesetzt werden können. Im Folgenden wird die Anwendung des RE-Ansatzes exemplarisch für das Requirements Engineering im Entwicklungsprozess innerhalb einer wohlverstandenen Domäne sowie für das Requirements Engineering in der Entwicklung eines in wesentlichen Aspekten innovativen Systems beschrieben.
4.1 Anwendung in einer etablierten und verstandenen Domäne Ein Entwicklungsprozess in einer etablierten und verstandenen Domäne zeichnet sich dadurch aus, dass bereits eine Vielzahl von Systemen mit gleichen oder ähnlichen Eigenschaften erfolgreich realisiert wurde. Das typische Entwicklungsziel eines solchen Entwicklungsprozesses besteht darin, ein klar umrissenes Inkrement von bereits entwickelten Systemen zu realisieren. Mögliche Beispiele für solche Domänen sind „Entwicklung der nächsten Generation von Motorsteuergeräten“ oder „Entwicklung der Software für ein neues Walzwerk“. Aus diesen Voraussetzungen ergibt sich unmittelbar, dass bereits zahlreiche Entwicklungsartefakte vorhanden sind (Anforderungen, Designartefakten und Implementierungsartefakten) und im Rahmen des aktuellen Entwicklungsprozesses wiederverwendet werden können. Die essenzielle Herausforderung besteht daher darin, die vorhandenen Artefakte derart anzupassen, dass das geplante Inkrement realisiert werden kann. Des Weiteren folgt aus den zuvor genannten Voraussetzungen, dass ein umfassendes Verständnis über die Strukturierung des geplanten Systems vorhanden ist, woraus sich nahezu unmittelbar eine Strukturierung der Abstraktionsstufen des geplanten Systems ableiten lässt. Beispiele für verstandene Strukturen für Abstraktionsstufen sind die Automatisierungspyramide aus der Industrieautomatisierung oder die Abstraktionsstufenstruktur aus der Avionik. Im Folgenden werden typische Schritte für die Anwendung des Ansatzes in einer etablierten und verstandenen Domäne beschrieben.
4.2 Typische Vorgehensweisein einer etablierten und verstandenen Domäne Die nachfolgenden Schritte beschreiben die idealisierte Vorgehensweise der Anwendung des RE-Ansatzes in einer etablierten und verstandenen Domäne: -
-
Schritt 1. Definition der Abstraktionsstufenstruktur: Im ersten Schritt der Anwendung wird die Abstraktionsstufenstruktur für das geplante System definiert. Diese Struktur sollte basierend auf den Erfahrungen von Vorgängerprojekten definiert werden. Schritt 2. Formulierung des gewünschten Entwicklungsinkrements: Im zweiten Schritt muss das gewünschte Entwicklungsinkrement für das geplante System beschrieben werden. Diese Formulierung sollte möglichst basierend auf Zielen erfolgen.
Zuletzt geändert: 29.04.2011, 14:45
21/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs -
Schritt 3. Analyse des gewünschten Entwicklungsinkrements: Mit Hilfe von Zielund Szenariomodellen und ohne Berücksichtigung der Abstraktionsstufen wird in diesem Schritt das gewünschte Entwicklungsinkrement detailliert analysiert und aufbereitet. - Schritt 4. Einordnung in Abstraktionsstufenstruktur: Die unter Schritt 3 formulierten Ziele und Szenarien werden in die unter Schritt 1 definierte Abstraktionsstufenstruktur eingeordnet. Ggf. muss eine Zerlegung und Neuformulierung der Ziele und Szenarien erfolgen, um eine eindeutige Zuordnung gemäß der definierten Abstraktionsstufenstruktur zu ermöglichen. - Schritt 5. Erfassung bestehender Anforderungen und Lösungskonzepte: Die formulierten Szenarien werden in Bezug auf bereits bekannte Anforderungen und Lösungskonzepte untersucht. Identifizierte Anforderungen und Lösungskonzepte werden mit Hilfe der definierten Modelle in den jeweiligen Abstraktionsstufen dokumentiert. - Schritt 6. Analyse in Bezug auf Anpassung für das Entwicklungsinkrement: Die in den vorherigen Schritten erstellten Anforderungen und Lösungskonzepte werden auf mögliche Änderungen und Anpassungen in Bezug auf die Realisierung des Entwicklungsinkrements untersucht. Die zuvor beschriebenen Schritte sind als idealisierte Aktivitäten zu betrachten, da die Schritte typischerweise nicht in Form getrennter Aktivitäten erfolgenden. Vielmehr werden insbesondere die Schritte 4-6 parallel und iterativ durchgeführt. Beispielsweise kann bereits bei der Einordnung der Artefakte in die Abstraktionsstufen (Schritt 4) die Analyse auf mögliche Anpassungen erfolgen (Schritt 6).
4.3 Anwendung zur Entwicklung eines innovativen Systems Ein Entwicklungsprozess für ein innovatives System zeichnet sich dadurch aus, dass ein System in dieser Form noch nicht realisiert wurde und auch keine unmittelbar vergleichbaren Systeme existieren. Diese Situation ist ebenso dadurch gekennzeichnet, dass noch keine geeignete Abstraktionsstufenstruktur für das geplante System existiert. Die Abstraktionsstufenstruktur wird daher erst im Verlauf des Entwicklungsprozesses zusammen mit dem fortschreitenden Verständnis über das geplante System erarbeitet. Aufgrund des innovativen Charakters des geplanten Systems ist es im Verlauf des Entwicklungsprozesses durchaus möglich, dass sich die bisherige Abstraktionsstufenstruktur für das geplante System als ungeeignet erweist und daher verworfen werden muss.
4.4 Typische Vorgehensweise zur Entwicklung eines innovativen Systems Die nachfolgenden Schritte beschreiben die idealisierte Vorgehensweise der Anwendung des RE-Ansatzes zur Entwicklung eines innovativen Systems: -
-
Schritt 1. Einordnung und Modellierung des Systems in seine Umgebung. Im ersten Schritt muss das System in seine zukünftige Umgebung eingeordnet werden, um die Interaktion anderer Systeme und Akteure mit dem System analysieren zu können und so Ziele und gewünschtes Verhalten festlegen zu können. Schritt 2. Formulierung der Ziele für das innovative System: Im zweiten Schritt müssen die Ziele formuliert werden, die durch das innovative System erreicht werden sollen.
Zuletzt geändert: 29.04.2011, 14:45
22/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs -
-
-
Schritt 3. Analyse des innovativen Systems als Blackbox: Mit Hilfe von Ziel- und Szenariomodellen wird in diesem Schritt das innovative System detailliert analysiert und aufbereitet. Da noch keine Abstraktionsstufenstruktur vorhanden ist, wird das geplante System zunächst als Blackbox betrachtet, d.h. die Ziele und Szenarien dürfen keine Annahmen über den inneren Aufbau des geplanten Systems machen. Schritt 4. Modellierung des innovativen Systems als Blackbox: Basierend auf den unter Schritt 3 formulierten Szenarien wird das geplante System als Blackbox modelliert. Hierzu können abhängig von der Beschaffenheit der unter Schritt 3 beschrieben Szenarien entweder Funktionsmodelle oder Verhaltensmodelle verwendet werden. Die Modellierung sollte in diesem Schritt noch möglichst auf essenzielle bzw. idealisierte Eigenschaften der Schnittstellen fokussieren und möglichst unabhängig von einer Lösung geschehen. Damit wird in diesem Schritt die oberste Abstraktionsstufe definiert. Schritt 5. Verfeinerung der Blackbox: Die in Schritt 4 modellierte Blackbox-Sicht des geplanten Systems wird in diesem Schritt verfeinert und damit eine zweite Abstraktionsstufe definiert. Wenn die im vorherigen Schritt formulierte idealisierte Sicht nicht auf ein technisches Konzept übertragen werden kann (bspw. kein Sensor für die Erfassung eine gewisse Information zur Verfügung steht), dann sollten die idealisierten Eigenschaften schrittweise konkretisiert werden.
Zuletzt geändert: 29.04.2011, 14:45
23/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
5 Zusammenfassung In diesem Dokument wurde die Projektschablone zur Unterstützung des modellbasierten Requirements-Engineering-Ansatz erläutert. Die Projektschablone wurde als Enterprise Architect Projektdatei implementiert und bildet das Abstraktionsebenenmodell und das Artefaktmodell des initialen RE-Ansatzes auf die EA-Paketstruktur ab. Die durch die Anwendung des RE-Ansatzes in Fallbeispielen (insbesondere die Fallbeispiele „Motorsteuerung“, „AV-Klimaanlage“ und „Zylinderkopffertigungsanlage“) wurde die Notwendigkeit einiger Änderungen am initialen RE-Ansatz notwendig. Diese Änderungen wurden in diesem Dokument beschrieben. Auf die zur Anwendung dieses Ansatzes notwendigen SysML-Profile wurde bei der Erläuterung der Schablonenstruktur verwiesen und die Anwendbarkeit wurde exemplarisch anhand eines durchgehenden Beispiels gezeigt. Abschließend wurde die Anwendung des RE-Ansatzes unter Zuhilfenahme der in diesem Dokument beschriebenen Projektschablone in zwei typischen Entwicklungsszenarien skizziert. Die Anwendbarkeit dieses Ansatzes, der Projektschablone und der zugehörigen SysML-Profilen werden derzeit im Rahmen der Fallbeispiele „Motorsteuerung“ und „AV-Klimaanlage“ weiter evaluiert. Die Erkenntnisse dieser Evaluierung sind zum Teil bereits in diesem Dokument verarbeitet worden. Zukünftige Arbeiten umfassen zudem die weitere Verbesserung des Ansatzes anhand der bei der Evaluierung durch Fallbeispiele erhaltenen Erkenntnisse.
Zuletzt geändert: 29.04.2011, 14:45
24/25
Deliverable D2.4B: Leitfaden für diemodellbasierte Dokumentation von Anforderungen und Entwurf für Embedded Systems über mehrere Abstraktionsstufen hinweg mittels eines kommerziellen Modellierungswerkzeugs
6 Literaturverzeichnis [DaSiLa10]
Daun, Marian; Sikora, Ernst; Lauenroth, Kim. Stand der Praxis im modellbasierten Requirements Engineering. SPES 2020 Deliverable D2.1.A, 2010. [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. [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. [SiTePo11] Sikora, Ernst; Tenbergen, Bastian; Pohl, Klaus. Requirements Engineering for Embedded Systems – An Investigation of Industry Needs. Proceedings of REFSQ 2011. [TeAvDaWe11a] Tenbergen, Bastian; Avramova, Nadezhda; Daun, Marian; Weyer, Thorsten. SysML-Profil und MDG-Plug-In für Enterprise Architect zur Szenariomodellierung auf Basis von SysML. SPES 2020 Teilergebnis, Version 1.0 vom 02.03.2011 [TeDaSiSt10] Tenbergen, Bastian; Daun, Marian; Sikora, Ernst; Stallbaum, Heiko. UML/SysML Profil und MDG-Plug-In für Enterprise Architect zur Modellierung von KAOS-Zieldiagrammen auf Basis von UML/SysML. SPES 2020 Teilergebnis, Version 1.2 vom 13.10.2010 [TeGaDaWe11b] Tenbergen, Bastian; Gabrisch, Sebastian; Daun, Marian; Weyer, Thorsten. SysML-Profil und MDG-Plug-In für Enterprise Architect zur Modellierung lösungsorientierter Anforderungen auf Basis von SysML. SPES 2020 Teilergebnis, Version 1.1 vom 14.04.2011
Zuletzt geändert: 29.04.2011, 14:45
25/25
