Dr. Andreas Froese Universität Duisburg-Essen

Transkript

1 Durchgängiges Requirements Engineering für die modellbasierte Entwicklung von softwareintensiven Embedded Systems und dessen Transfer in die industrielle Anwendung Dr. Andreas Froese Universität Duisburg-Essen

2 paluno The Ruhr Institute for Software Technology 2

3 Forschungsschwerpunkte Gruppe Prof. Klaus Pohl Requirements Engineering Embedded / Cyber-Physical Systems Variabilitäts- Management Future Internet Applications Cloud Computing Services / SOA Adaptive Systeme Cockpits & Leitstände Security, Privacy & Trust Domänen Energie Transport & Logistik Automotive 3

4 Problemstellung Komplexer Kontext in den Systeme eingebunden sind Interaktion/Beeinflussung mit/durch andere(n) Systeme(n) Z.B. modularer Sicherheitsnachweis (Großer) Schwachpunkt bestehender Ansätze: à Modelle können nicht (oder nur unzureichend) miteinander in Beziehung gesetzt werden (Traceability von Requirements) àumfassende Betrachtung/Bewertung des Systems nicht möglich 4

5 Überblick SPES-Projekte SPES Modeling Framework Requirements Viewpoint Entwicklungssystematiken Transfer in die industrielle Anwendung Zusammenfassung 5

6 SPES 2020 und SPES XT (Softwareplattform Embedded Systems) Projektlaufzeit: 11/ /2012 und 05/ /2015 Projektvolumen: ca. 65 Mio. Euro BMBF-Förderung Industrielle Partner Airbus Operations GmbH Audi Electronics Venture GmbH Berlin Heart GmbH Berner & Mattner Systemtechnik GmbH Cassidian Daimler AG EADS-Deutschland GmbH Embedded4You e.v. Fortiss GmbH Hella KGaA Hueck & Co. INCHRON GmbH IT Power Consultants Itemis GmbH Liebherr Aerospace Lindenberg GmbH Akademische Partner Fraunhofer-Institut für Experimentelles Software Engineering (IESE) Fraunhofer-Institut für Rechnerarchitektur und Softwaretechnik (FIRST) OFFIS e.v. Technische Universität Kaiserslautern Technische Universität München Universität Duisburg-Essen Universität Paderborn Pure-Systems GmbH Robert Bosch GmbH RWE Deutschland AG SWM Services GmbH Siemens AG TeCNeT GmbH TÜV Süd AG Vector Informatik GmbH 6

7 SPES (Kern-)Prinzipien / Methoden Modellbasierte Entwicklung von Embedded Systems Systembetrachtung mittels Viewpoints Problem und Lösung logischer Lösung und technischer Lösung Explizite Berücksichtigung der Dekomposition des Systems ( Teile-und-Herrsche ) ALLE Modelle, die verwendet werden, zueinander (formal) in Beziehung setzen 7

8 Initial Final Initial AutoMode Anlage eingeschaltet [UserInput =!AutoMode] [UserInput: terminieren] [UserInput: einschalten] [UserInput = AutoMode] [UserInput: einschalten] Anlage ausgeschaltet AutoMode Sensor OperationOn ManualMode AutoMode Sensor Bewegungsauftrag Crane1 Sensordaten verarbeiten Funktionen des TransportationController OperationOn Bewegungsauftrag Crane1 Bewegungsauftrag Crane2 OperationOn Crane1Action Crane1Sensor Wegpunkte für Crane1 berechnen Wegpunkte für Crane2 berechnen Bewegungsauftrag Crane2 Förderbandbew egungen berechnen Crane2Action Crane2Sensor Action Sensor Crane1Action Crane2Action SupplyBandAction SupplyBand DeliveryBand +Bus-conformant Data SupplyBandSensor Deliv erybandaction Crane1Action Crane2Action SupplyBand +Displayed data DeliveryBand Representation SystemOuput Deliv erybandsensor translated by IOAdapter Crane1ActionSignal Determination Crane1SensorSignal +Raw Signal +represented Information +determined Crane2ActionSignal OperationOn +determins +Raw Data translated by IOAdapter +Translated Signal ActionSignal UserInput SensorSignal Crane2SensorSignal SupplyBandActionSignal AutoMode SupplyBandSensorSignal Deliv erybandactionsignal Deliv erybandsensorsignal Modellbasiertes Engineering Dokumentbasiertes Engineering Modellbasiertes Engineering Architekturartefakte Requirement Spec System Anforderungsartefakte Spec R1 Dokumentation RN solution-oriented system requirements Architecture Spec Tests [ ] Simulationsartefakte Testartefakte 8

9 Überblick Viewpoints (1/2) Requirements Viewpoint Modellierungsziele: Dokumentation des Systemkontext Dokumentation der Ziele und zughöriger Szenarien der Stakeholder Spezifikation der zur Zielerreichung notwendigen fachlichen Eigenschaften/Anforderungen Aktivitäten Systematische Gewinnung von Anforderungen Spezifikation von Anforderungen Validierung von Anforderungen Functional Viewpoint Modellierungsziele: Dokumentation der funktionalen Anforderungen und dessen Abhängigkeiten (à Systemspezifikation) Aktivitäten Validierung von Anforderungen Generierung von Testfällen und Verifikationsbedingungen 9

10 Überblick Viewpoints (2/2) Logical Viewpoint Modellierungsziele: Logische Beschreibung der Lösung durch Zerlegung in Teilsysteme Plattformunabhängigkeit der beschriebenen Lösung Aktivitäten Verifikation des Systemverhaltens (z.b. durch Simulation) Technical Viewpoint Modellierungsziele: Plattformspezifische Beschreibung der (Software-)Subsysteme Beschreibung der Ziel-Hardware (ECUs, Busse, Speicher, ) Definition von (Software-)Tasks und Scheduler Aktivitäten Deployment / Softwareverteilung 10

11 Granularität und Dekomposition Granularität: Anzahl von Untergliederungen eines Elements [Duden] n S Dekomposition (D) grob Granularitätsebene n+1 n+2 S1 S2 S3 D D D S1.1 S1.2 S2.1 S2.2 S3.1 S3.2 S3.3 Grad der Granularität D D D + n+3 fein 11

12 Überblick SPES-Projekte SPES Modeling Framework Requirements Viewpoint Entwicklungssystematiken Transfer in die industrielle Anwendung Zusammenfassung 12

13 Umsetzung der SPES (Kern-)Prinzipien Betrachtung verschiedener Viewpoints (nach ISO/IEC 42010) zur Differenzierung und zum strukturierten Übergang zwischen: Problemanalyse und Lösungskonstruktion logischer Lösung und technischer Lösung Explizite Unterscheidung von Granularitätsebenen der Systembetrachtung und zugehöriger Dekompositionsbeziehungen Artefaktmodell mit definierter genereller Semantik der Artefakt(typen) und der Beziehung zwischen Artefakttypen 13

14 SPES Modeling Framework Basis-Viewpoints Viewpoints Requirements Functional Logical Technical grob Granularitätsebenen fein

15 Integration der Views (beispielhaft) Voraussetzung für die Durchgängigkeit (insb. methodisch) ist, dass die Modelle der verschiedenen Views semantisch zueinander in Beziehung gesetzt werden. Requirements Viewpoint Functional Viewpoint Logical Viewpoint Technical Viewpoint System C1 C2 ECU 1 ECU 2 F 1 F 2 C3 Bus 15

16 Überblick SPES-Projekte SPES Modeling Framework Requirements Viewpoint Entwicklungssystematiken Transfer in die industrielle Anwendung Zusammenfassung 16

17 Artefakte des Requirements Viewpoints Kontext Ziele Szenarien Lösungskonzeptbezogene Anforderungen gibt den Rahmen vor detaillieren an Beispielen sind Grundlage für 17

18 Operationeller Kontext Der Operationelle Kontext eines Systems umfasst alle Aspekte der Umgebung des betrachteten Systems, d.h. das Verhalten des betrachteten Systems im Betrieb potenziell beeinflussen. Hierzu zählen z.b. andere Systeme, menschliche Akteure oder auch technische, physikalische Prozesse, Geschäftsprozesse. Analyse und Dokumentation aus drei Perspektiven KF Menschen A Prozesse (techn./phys./ ) System Future Internet (Dienste/Daten) KF KF SF KF KF D S B Operationelle Kontext andere Systeme KF Statisch-strukturell Funktional Verhalten KF C 18

19 Ziele im RE Ein Ziel charakterisiert eine Intentionen von Stakeholdern in Bezug auf das betrachtete System. Systemverständnis Stakeholder-Nähe Abstimmung Exploration möglicher Lösungen Validierung Vollständigkeit Frühe Identifikation von Konflikten Detektion irrelevanter Anforderungen Anforderungsgewinnung Ausgangspunkt der Anforderungserhebung Begründung für Anforderungen Adaptive Geschwindigkeitsregelung AND Einhaltung von gesetzlichen Restriktionen AND Sicherheit AND Komfort Sicherheitsabstand nicht unterschreiten Beschleunigungsmaximum einhalten Fahrer akustisch warnen bei möglicher Kollision Umgebung warnen AND Erkennen von Verkehrsschilder Fahrzeuge erkennen Veränderungen vorherfahrender Fahrzeuge 19

20 Szenarien im RE Ein Szenario ist eine sachlogisch zusammenhängende Folge von Interaktionen zwischen Akteuren im Kontext und dem betrachteten System, z.b. Erfüllung eines Ziels, Reaktion auf eine aufgetreten Ausnahmesituation. Hohe Abstraktion Systemverständnis Abstimmung Exploration möglicher Lösungen Niedrige Abstraktion Untersuchung detaillierter Anforderungen Begründung für Anforderungen Validierung der Anforderungen Navigationssystem Fahrer exc Zieleingabe anfordern Zieleingabe [Abbruch durch Fahrer] Navigation abbrechen Route anzeigen Typen von Szenarien: - Hauptszenarien - Alternativszenarien - Ausnahmeszenarien und - Negativ-Szenarien - Security-Szenarien - Safety-Szenarien - 20

21 Lösungskonzeptbezogene Anforderungen Eine Lösungskonzeptbezogene Anforderung definiert eine Eigenschaft, die das betrachtete System in Bezug auf ein konkretes Lösungskonzept an seiner Schnittstelle aufweisen muss, damit es im Betrieb seinen Systemzweck erfüllen kann * 0..* 1 z.b. Klassendiagramme. Anforderung (natürlichsprachlich) System Stellt ein Glasbruchsensor fest, dass die Glasscheibe beschädigt wurde, soll das System nach spätestens 2 Sekunden den Sicherheitsdienst benachrichtigen. z.b. Zustandsdiagramm Funktionsmodell Funktion: Sicherheitsdienst benachrichtigen z.b. Aktivitätsdiagramme 21

22 Datenperspektive bei der Spezifikation von Anforderungen Beispiel: Aufmerksamkeitsassistent (AMA) Spezifikation der notwendigen fachlichen Informationsstruktur von ein- und ausgehenden Daten Attributierung der Begriffe bzw. Daten: Welche fachlichen Eigenschaften von Daten bzw. Begriffen sind relevant? Textuelle Requirements (Auszug): R7: Bezüglich der Konstitution des Fahrers muss das AMA zwischen den folgenden Aufmerksamkeitsstatus unterscheiden: Ideal, Eingeschränkt, Eingeschlafen, Ohne Reaktion. UML-Klassendiagramme 22

23 Funktionsperspektive bei der Spezifikation von Anforderungen Beispiel: Aufmerksamkeitsassistent (AMA) Spezifikation der Anforderungen in Bezug auf die fachlich notwendigen Funktionen und deren Abfolge Spezifikation der Abfolge von Funktionen in Form von Sequenzen von Funktionen, bedingter Verzweigungen und Nebenläufigkeit Liedschlag auffällig oder Fahrerhalten auffällig Liedschlag und Fahrerhalten unauffällig Textuelle Requirements (Auszug): R17: Nachdem der AMA die Warnung der Warnstufe 1 ausgelöst hat, fordert das MES eine Fahrerbestätigung an. R18: Erfolgt keine Bestätigung der Warnung durch den Fahrer, muss der AMA eine Warnung der Warnstufe 2 auslösen. R19: Erfolgt eine Bestätigung der Warnung durch den Fahrer Bestätigung erfolgt SysML-/UML-Aktivitätsdiagramme 23

24 Verhaltensperspektive bei der Spezifikation von Anforderungen Beispiel: Aufmerksamkeitsassistent (AMA) Betrachtet das notwendige zustandsbasierte Verhalten des Systems, d.h. dessen fachlich notwendige Reaktion auf externe Stimuli in Form von erlaubten Zuständen, Zustandsänderungen und erzeugten Ausgaben. Textuelle Requirements (Auszug): R47: Nachdem der Fahrer bei nicht idealer Aufmerksamkeit eine Fahrpause von mehr als 30 Minuten eingelegt hat wird die Aufmerksamkeit des Fahrers beim Fahrantritt mit eingeschränkt beurteilt. R49: Wenn der Fahrer eine eingeschränkte Aufmerksamkeit hat und die Liedschlagfrequenz kritisch ist, dann wird dessen Aufmerksamkeit mit Einschlafgefahr beurteilt. SysML-/UML-Zustandsmaschinendiagrammen 24

25 Integration der Modellierungsperspektiven 1 Objekt Zustand [Ereignis] [Ereignis] Zustand Zustand Aktion [Ereignis] / Aktion Verhaltensperspektive (hier: Zustandsmaschine) [Ereignis] 2 Objekt Attributwert Attributwert Attributwert Objekt Attributwert Aktion Datenperspektive (hier: Objektdiagramm als Funktionsperspektive Instanz eines Klassendiagramms) (hier: Aktivitätsdiagramm) 4 3 [O] [O] Aktion Aktion [O] [O] Aktion 25

26 Überblick SPES-Projekte SPES Modeling Framework Requirements Viewpoint Entwicklungssystematiken Transfer in die industrielle Anwendung Zusammenfassung 26

27 Mögliche Entwicklungssystematiken (A) Basis- Viewpoints Requirements Functional Logical Technical Granularitätsebenen

28 Mögliche Entwicklungssystematiken (B) Basis- Viewpoints Requirements Functional Logical Technical Granularitätsebenen

29 Mögliche Entwicklungssystematiken (C) Iterative-inkrementelles Vorgehen Basis- Viewpoints Granularitätsebenen 70% 90% 100% 50% 70% 90% 20% 50% 30% 60% 20% 40% 50% Entwicklungszyklus I Entwicklungszyklus II Entwicklungszyklus III Inkremente Vollständigkeit der View Requirements VP Functional VP Technical VP Iteration Logical VP 29

30 Überblick SPES-Projekte SPES Modeling Framework Requirements Viewpoint Entwicklungssystematiken Transfer in die industrielle Anwendung Zusammenfassung 30

31 SPEDiT (Softwareplattform Embedded Systems Dissemination and Transfer) Projektlaufzeit: 01/ /2018 Projektvolumen: ca. 7,5 Mio. Euro BMBF-Förderung Industrielle Partner Berlin Heart GmbH GPP Communication GmbH & Co. KG Parametric Technology GmbH - PTC Schaeffler Technologies AG & Co. KG Validas AG Akademische Partner Fortiss GmbH Technische Universität München Universität Duisburg-Essen Universität Ulm Technische Universität Berlin 31

32 SPEDiT (Softwareplattform Embedded Systems Dissemination and Transfer) Pyramide der Lernziel-Level Rollen (basierend auf Personas) System Architect System Requirements Engineer Test Engineer Software Architect Software Developer 32

33 Zusammenfassung 33

34 Dr. Andreas Froese Tel.: 0201 / Mail: andreas.froese@paluno.uni-due.de 34

35 Backup-Folien 35

36 Viewpoint und Views View Viewpoint Vorgaben zur Erstellung einer spezifischen View z.b. tabellarische Definition des SPES Requirements Viewpoints Anwendung des Viewpoints auf ein spezifisches (Teil-)System zur Erstellung der entsprechenden View z.b. Requirements View (Anforderungen) für ein spezifisches (Teil-)Systems In Anlehnung an: IEEE 42010

37 exc Zieleingabe Zieleingabe anfordern Navigationssystem Fahrer Ziele und Szenarien in Use-Case-basierten Ansätzen Ein Use Case charakterisiert eine an der Systemgrenze von Nutzern wahrnehmbare Funktionalität des Systems, die, vollständig ausgeführt ( Ende-zu-Ende ), einen Mehrwert für einen oder mehrere Nutzer (Akteure) im Kontext erbringt. Actor Use Case Diagramm System <<include>> <<extend>> <<system>> Actor Use Case Spezifikation Einhaltung von Use Case Sicherheitsabstand nicht unterschreiten Akteure gesetzlichen Restriktionen AND Mehrwert Vorbedingung Trigger Adaptive Geschwindigkeitsregelung AND Beschleunigungsmaximum einhalten Fahrer akustisch warnen bei möglicher Kollision Nachbedingung Szenarien (Haupt/Alternativen/Ausnahme Sicherheit AND Erkennen von Verkehrsschilder Umgebung warnen AND Fahrzeuge erkennen Veränderungen vorherfahrender Fahrzeuge Komfort [Abbruch durch Fahrer] [Abbruch durch Fahrer] Route anzeigen Fahrer] durch [Abbruch [Abbruch durch Fahrer] Navigation abbrechen Navigation abbrechen Zieleingabe anfordern Navigationssystem Fahrer Navigation abbrechen Zieleingabe anfordern Navigation abbrechen [Abbruch durch Fahrer] [Abbruch durch Fahrer] [Abbruch durch Fahrer] Navigation abbrechen Zieleingabe anfordern Navigationssystem Fahrer Navigation abbrechen Zieleingabe anfordern Navigation abbrechen Navigationssystem Fahrer Navigation abbrechen Navigationssystem Fahrer Navigationssystem Fahrer Navigationssystem Fahrer exc exc exc Navigationssystem Fahrer exc Route anzeigen Route anzeigen Route anzeigen Zieleingabe Zieleingabe anfordern Zieleingabe Zieleingabe anfordern Zieleingabe Zieleingabe exc exc Route anzeigen Route anzeigen Route anzeigen Zieleingabe Zieleingabe [Abbruch durch Fahrer] exc Route anzeigen Zieleingabe Zieleingabe anfordern

38 Der Systembegriff Ein System hat: Kontextgrenze 1. einen operationellen Kontext, der das System im Betrieb beeinflusst bzw. von diesem beeinflusst wird 2. Schnittstellen, die es eindeutig von seinem Kontext abgrenzt 3. Verhalten, das an diesen Schnittstellen beobachtbar ist sowie 4. eine innere Struktur aus zueinander in Beziehung stehenden Elementen. Prozesse Schnittstelle (techn./phys./ ) Operationelle Kontext Menschen System andere Systeme Future Internet (Dienste/Daten) Innere Systemstruktur

39 Lösungskonzeptbezug am Beispiel Der Fahrer des Fahrzeuges möchte stets eine sichere Distanz zum vorausfahrenden Fahrzeug einhalten Ziel Lösungskonzept 1: Abstandssensorik Lösungskonzept 2: Inter-Car-Kommunikation... Lösungskonzeptbezogene Anforderung (textuell) - R1.1a: Das System soll den Abstand zum vorausfahrenden Fahrzeug messen - - R1.3.a: Wenn das System ein vorausfahrendes Fahrzeug detektiert hat, muss das System die Geschwindigkeit des vorausfahrenden Fahrzeuges bestimmen. Lösungskonzeptbezogene Anforderung (textuell) - R1.1b: Das System muss alle 100ms die aktuelle Position und die aktuelle Geschwindigkeit in das Netz senden. - R.1.2b: Das System muss die empfangenen Geschwindigkeitsdaten und Positionsdaten anderer Fahrzeuge in einem Umkreis von 200 Metern auswerten und vorhalten. -