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

Wiederholung Domänenanalyse kardiovaskuläre Hilfssysteme? Systemkomponenten Herzschrittmacher? Gerätemodi, Betriebsmodi? Was versteht man unter Anforderungsanalyse? Wichtige Eigenschaften von Anforderungen? Traceability: wohin, wozu? Funktionalität von RM-Tools?

Polarion Requirements / ALM

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

Modellierung von Zielen: SysML UML nicht ideal für Systems Engineering (Software-Modellierung) Aber: Profil-Mechanismus existiert (seit UML2 in der Sprache)

SysML Diagrammarten 14:44

Abstrakte Syntax von SysML / UML Jedes Modell besteht aus Elementen, die durch Relationen verbunden sind Relationen sind selbst auch Modellelemente Relationen können gerichtet sein und Vielfachheiten besitzen Abstraktion, Assoziation und Komposition sind gerichtete Relationen

UML / SysML Views Modell ist ungleich der Modellsicht! Modellsicht bietet einen Ausschnitt des Modells Geschickte Wahl der Sicht zur Verdeutlichung Löschen in der Ansicht bedeutet nicht Löschen im Modell

SysML Requirements Diagramme Verbindung zwischen informeller und formaler Notation Integration von Anforderungstexten in ein Modell Relationen zwischen Anforderungen (include, derive, …) Relationen zu anderen Modellelementen (verify, satisfy, …) Toolsupport: Eclipse-Papyrus (sowie fast alle kommerziellen UML-Tools)

Requirements Diagramm: Beispiel

Pacemaker in Papyrus

Anforderungen: 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

Beispiel Schrittmacher Der Schrittmacher arbeitet im Betriebsmodus „permanent“ mit der Frequenz f. Der Patient bewegt sich mit einer Aktivität unterhalb des Schwellwerts. Der Patient erhöht die Aktivität oberhalb des Schwellwerts. Der Schrittmacher erhöht die Frequenz um den Reaktionsfaktor. Der Patient erhöht die Aktivität weiter. Der Schrittmacher erhöht die Frequenz nur bis zur maximalen Sensorrate. Der Patient verringert seine Aktivität unterhalb des Schwellwerts. Nach der festgelegten „recovery time“ verringert der Schrittmacher die Frequenz.

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

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