Modellbasierte Software-Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

Anforderungsdefinition Ungefähre Struktur: Embedded Systems: HW, SW, Programmierung, Anforderungen, Softwareprozesse, Automotive SWE Modellierung und Codegenerierung UML, OCL, etc. Simulink Validierung, Verifikation, Testgenerierung, Testautomatisierung Architekturen: Sensorik, Bussysteme, OS, Middleware, Autosar,... Entwicklung sicherheitskritischer Systeme Normen und Standards (ISO 26262, DO-178B) Risiko- und Sicherheitsanalysen Modellbasierte Entwicklung sicherheitsrelevanter Software Fehlertoleranz Werkzeugeinsatz und Toolqualifikation Spezialthemen: Design-Pattern, Security, Multicore, ...

Anforderungsanalyse Motivation, Problematik, Methodik systematische Vorgehensweisen Beispiel Türsteuergerät Werkzeuge W. Pohl, Requirements Engineering: Grundlagen, Prinzipien, Techniken. Springer 2007

Motivation Anforderungsanalyse Vergleich zum Vorgehen eines Ingenieurs: Plan auf Papier Analyse des Plans Bau des Systems Software: Wunschvorstellungen Implementierung und Test Ändern solange bis Ergebnis zufriedenstellend  Das kann‘s nicht sein! Wie werden Anforderungen systematisch erfasst und verwaltet? Wie fließen sie in den Entwurf ein?

Aufgaben bei der Anforderungsanalyse Anforderungserhebung (Requirements elicitation) Kommunikation mit Kunden und Benutzern um festzustellen, was die Anforderungen sind; Vorstudie Anforderungserfassung (Requirements recording) Gruppierung und Aufschreibung der Anforderungen in einer bestimmten Form, z.B. als Texte, Grafiken, Anwendungsfallbeschreibungen, Prozess-Spezifikationen usw. Anforderungsprüfung (Requirements checking) Bestimmung ob die Anforderungen verständlich, eindeutig, vollständig und widerspruchsfrei sind Anforderungsverfolgung (Requirements tracing) Verknüpfung der Anforderungen zu anderen Entwurfsartefakten wie Modellen, Code und Testfällen

Ziele der Anforderungsanalyse Erstellung bzw. Erhaltung eines qualitativ hochwertigen Satzes von Anforderungen als ultimative Referenz für das System Schwierigkeit: kontinuierlicher Wandel! Haupt-Belange Festlegung des Systemumfangs und der Systemgrenzen Festlegung des Systemverhaltens Verwaltung der Beziehung und Prioritäten zwischen Anforderungen Verwaltung der Querbezüge innerhalb der Anforderungen zu Spezifikation, Implementierung, Test zu anderen Dokumenten und Artefakten Änderungsmanagement für Anforderungen

Typen von Anforderungsdokumenten Benutzeranforderungen (Lastenheft, “User Req. Spec.”) Beschreibung der durch das System bereitgestellten Dienste und operationalen Randbedingungen; in der Sprache des Kunden bzw. Nutzers verfasst und für diesen verständlich; Grundlage für Auftragserteilung Systemanforderungen (Pflichtenheft, “System Req. Spec.”) Strukturiertes Dokument, welches eine vollständige und detaillierte Beschreibung aller Systemschnittstellen und -funktionen enthält, einschließlich interner Schnittstellen; in der Sprache der Implementierer bzw. Tester verfasst, Grundlage für nachfolgende Systementwicklung SRS wird oftmals weiter aufgeteilt in Software Requirements Specification / Document Hardware Requirements Specification / Document

Beispiel URS - SRS

Anforderungen – für wen?

Anforderungen eingebetteter Systeme Physikalische Umgebung spezielle operationale Randbedingungen, z.B. Temperatur, Beschleunigungswerte Abmessungen, Formfaktor, Stecker usw. Technisches System mit HW und SW Kosten / Leistungsbeschränkungen Prozessor (-familie), max. Speicherausbau Sensorik / Aktuatorik Toleranzbereiche, Abweichungen Leistungsgrenzen Domänenspezifika Fachbegriffe Normen, Standards Funktion als Regelkreis und Schaltfunktion kontinuierliche und diskrete Anteile

Funktionale und nichtfunktionale Anforderungen Beschreibung der Dienste des Systems, z.B. wie es auf bestimmte Eingaben reagiert oder sich in bestimmten Situationen verhält z.B. was passiert wenn ein bestimmter Knopf gedrückt wird Nicht-funktionale Anforderungen Randbedingungen für die Dienste, z.B. zeitliche Einschränkungen, Entwicklungseinschränkungen, usw. z.B. Lebensdauer oder Leistung umstritten ob überhaupt NFR existieren Domänen-Anforderungen allgemeine Anforderungen für alle Systeme einer bestimmten Anwendungsdomäne (Medizintechnik, Schienenverkehr...) z.B. anwendbare Standards

Funktionale Anforderungen Funktionalität oder Dienste des Systems Funktionale Nutzeranforderungen: Abstrakte Außensicht Funktionale Systemanforderungen: Abstrakte Innensicht Formulierung hängt ab von der zu erwartenden Nutzung und dem Einsatzbereich des Systems BLACK BOX VIEW!

Nichtfunktionale Anforderungen

Anforderungsartefakte Pohl klassifiziert drei Arten von Artefakten: Ziele Szenarien Lösungsorientierte Anforderungen (Strategien)

Ziele Def.: (Pohl) Ein Ziel ist die intentionale Beschreibung eines charakteristischen Merkmals des zu entwickelnden Systems bzw. des zugehörigen Entwicklungsprozesses. Ziele verfeinern die Vision der Vorstudie berücksichtigen die Belange der „Stakeholders“ helfen, Konflikte aufzuzeigen und aufzulösen leiten die Gewinnung weiterer Anforderungen durch Verfeinerung an dienen zur Begründung von nachfolgenden Szenarien und Strategien und helfen, irrelevante Anforderungen zu identifizieren können zur Identifikation und Bewertung von Lösungsalternativen herangezogen werden

Die sieben Regeln zur Formulierung von Zielen Formulieren Sie die Ziele kurz und prägnant! Verwenden Sie Aktivformulierungen! Formulieren Sie überprüfbare Ziele! Verfeinern Sie nicht überprüfbare Ziele! Stellen Sie den Mehrwert eines Ziels dar! Geben Sie eine Begründung für das Ziel an! Formulieren Sie deklarativ, d.h. vermeiden Sie die Beschreibung von Lösungsansätzen! Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ

Prägnante Ziele Schlecht: Das geplante System soll sowohl von Experten als auch von unerfahrenen Personen (Nutzerinnen und Nutzern) benutzbar sein. Unerfahrene User sollen auch ohne große Vorkenntnisse der Bedienerführung oder des Vorgängersystems die vorgesehene Systemfunktionalität nutzen können. Zur Benutzung des Systems sollen die Anwender also keinerlei Schulungen oder spezielle Hilfestellungen benötigen. Der Umgang mit dem System muss daher leicht verständlich sein und ohne große Erfahrung mit dem Vorgängersystem oder vergleichbaren Systemen erfolgen können. Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: Ein unerfahrener Benutzer soll das System ohne spezielle Schulung verwenden können

Aktive Formulierungen Schlecht: Die Dauer für die Erfassung und Verarbeitung der Messdaten soll halbiert werden. Dadurch soll die Wartezeit bis zum Vorliegen von Ergebnissen verkürzt werden. Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: Das System erfasst und verarbeitet die Messdaten im Vergleich zum System xy doppelt so schnell. Dadurch muss der Nutzer kürzer auf das Vorliegen von Ergebnissen warten

Überprüfbare, quantitative Ziele Schlecht: Das System soll besser sein als das Vorgängersystem. Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: Das System soll folgende Verbesserungen gegenüber dem System xy bieten: …

Verfeinerung von Zielen Schlecht: Die Benutzung des Systems soll selbsterklärend sein Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: Das System soll selbsterklärend sein, d.h. ein durchschnittlicher Nutzer soll durchschnittlich nach 2 Min. folgende Funktionen aufrufen können: … Das System soll selbsterklärend sein, d.h. den Vorgaben nach W3C… in Bezug auf … folgen

Mehrwertbildung Schlecht: Das System soll leicht benutzbar sein. Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: Das System soll … so dass sich die Nutzer auf andere Aufgaben konzentrieren können

Nachvollziehbare Begründungen Schlecht: Das System soll auch von ungeschulten Benutzern intuitiv benutzbar sein. Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: … weil es auch in Mietfahrzeugen einsetzbar sein soll

keine Lösungsvorwegnahme Schlecht: Durch komprimierte Datenübertragung im Cache soll das geplante System um 10% kürzere Antwortzeiten aufweisen Prägnant Aktiv Überprüfbar Verfeinerbar Wertschöpfend Begründbar Deklarativ Besser: Das System soll um 10% kürzere Antwortzeiten aufweisen als System xy.

Schablone zur Formulierung von Zielen

Dekomposition von Zielen Und-Oder-Bäume vgl. Fehlerbaumanalyse (später) Komfortable und schnelle Navigation zum Zielort Umgehung von Verkehrsbehinderungen Komfortable Zieleingabe Automatische Navigation zum Zielort Manuelle Eingabe von Störungen in Straßen Selbständige Aktualisierung von Verkehrsdaten

Szenarien Def.: (Pohl) Ein Szenario beschreibt ein konkretes Beispiel für die Erfüllung bzw. Nichterfüllung eines oder mehrerer Ziele. Es konkretisiert dadurch eines oder mehrere Ziele. Ein Szenario enthält typischerweise eine Folge von Interaktionsschritten und setzt diese in Bezug zum Systemkontext. Szenarientypen Positive, negative, und Missbrauchsszenarien Deskriptive, explorative, oder erklärende Szenarien Systeminterne, Interaktive, Kontextszenarien Haupt-, Alternativ- und Ausnahmeszenarien Anwendungsfälle (Use Cases) gruppieren Szenarien

Beispiel „automatisches Bremsmanöver“ (nach Pohl) Der Fahrer fährt mit konstanter Geschwindigkeit auf der Autobahn. Das vorausfahrende Fahrzeug bremst scharf. Der Fahrer tritt auf das Bremspedal. Das System erkennt eine Unterschreitung des Sicherheitsabstands und gibt eine Warnung aus. Der Abstand zwischen den Fahrzeugen verringert sich weiter. Das System leitet eine automatische Vollbremsung ein und informiert den Fahrer über den Bremsvorgang. Als der Abstand sich nicht mehr verringert, beendet das System die automatische Vollbremsung. Danach stellt es den Mindestabstand zum vorausfahrenden Fahrzeug wieder her und informiert den Fahrer über die Rückgabe der Kontrolle. Was wird klar, was bleibt unklar?

Attribute von Szenarien Positiv: Wie wird das Ziel erfüllt? Negativ: Wie wird das Ziel nicht erfüllt? Missbrauchsszenarien: unerwünschte Verwendung Deskriptiv: verdeutlicht typische Abläufe Explorativ: verdeutlicht Lösungsraum Erklärend: verdeutlicht Gründe für Systemverhalten Systemintern: Handlungsstränge innerhalb des Systems Interaktiv: Handlungsstränge zwischen Akteuren Kontextszenarien: weitere Kontextinformationen Hauptszenario: wesentlicher Funktionsablauf Alternativszenario: partielle Abwandlung eines Hauptszenarios Ausnahmeszenario: Reaktion auf Ereignisse, die Hauptszenario verhindern

Szenario als strukturierte Folge von Schritten Der Fahrer schaltet das Navigationssystem ein. Das System ermittelt den aktuellen Standort des Fahrzeugs. Das System erfragt den gewünschten Zielort. Der Fahrer gibt den Zielort in das System ein. Das System ermittelt den benötigten Fartenausschnitt. Das System zeigt die Karte des Zielgebietes am Bildschirm an. Das System erfragt die Optionen für die Routenberechnung. Der Fahrer wählt die Optionen für die Routenberechnung. Das System bestimmt die Wegführung. Das System zeigt eine Erfolgsmeldung am Bildschirm. Das System stellt eine Liste von Wegpunkten zusammen. Das System zeigt den nächsten Wegpunkt der Navigation.

Tabelle

Schablone für Use-Cases Bezeichner, Name, Autoren, Version, Historie Priorität, Kritikalität, Quelle, Verantwortlicher Kurzbeschreibung Ebene, Ziele, Akteure Vorbedingung, Nachbedingung, Ergebnisausgaben Hauptszenario Alternativszenarien, Ausnahmeszenarien Qualitätsanforderungen Querverweise (Inclusionen, Generalisierungen)

Sequenz- diagramm

erweitertes Sequenz- diagramm

Aktivitäts- diagramm

Ziele und Szenarien