Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer."—  Präsentation transkript:

1 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

2 Folie 2 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme 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,...

3 Folie 3 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Anforderungsanalyse Motivation, Problematik, Methodik systematische Vorgehensweisen Beispiel Türsteuergerät Werkzeuge W. Pohl, Requirements Engineering: Grundlagen, Prinzipien, Techniken. Springer 2007

4 Folie 4 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme 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 kanns nicht sein! Wie werden Anforderungen systematisch erfasst und verwaltet? Wie fließen sie in den Entwurf ein?

5 Folie 5 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme 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

6 Folie 6 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme 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

7 Folie 7 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme 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

8 Folie 8 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Beispiel URS - SRS

9 Folie 9 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Anforderungen – für wen?

10 Folie 10 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme 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

11 Folie 11 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Funktionale und nichtfunktionale Anforderungen Funktionale 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

12 Folie 12 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme 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!

13 Folie 13 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Nichtfunktionale Anforderungen

14 Folie 14 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Anforderungsartefakte Pohl klassifiziert drei Arten von Artefakten: ZieleSzenarien Lösungsorientierte Anforderungen (Strategien)

15 Folie 15 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme 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

16 Folie 16 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Die sieben Regeln zur Formulierung von Zielen 1. Formulieren Sie die Ziele kurz und prägnant! 2. Verwenden Sie Aktivformulierungen! 3. Formulieren Sie überprüfbare Ziele! 4. Verfeinern Sie nicht überprüfbare Ziele! 5. Stellen Sie den Mehrwert eines Ziels dar! 6. Geben Sie eine Begründung für das Ziel an! 7. Formulieren Sie deklarativ, d.h. vermeiden Sie die Beschreibung von Lösungsansätzen! 1. Prägnant 2. Aktiv 3. Überprüfbar 4. Verfeinerbar 5. Wertschöpfend 6. Begründbar 7. Deklarativ

17 Folie 17 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Prägnante Ziele Besser: Ein unerfahrener Benutzer soll das System ohne spezielle Schulung verwenden können 1. Prägnant 2. Aktiv 3. Überprüfbar 4. Verfeinerbar 5. Wertschöpfend 6. Begründbar 7. Deklarativ 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.

18 Folie 18 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Aktive Formulierungen 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 1. Prägnant 2. Aktiv 3. Überprüfbar 4. Verfeinerbar 5. Wertschöpfend 6. Begründbar 7. Deklarativ 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.

19 Folie 19 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Überprüfbare, quantitative Ziele Besser: Das System soll folgende Verbesserungen gegenüber dem System xy bieten: … Schlecht: Das System soll besser sein als das Vorgängersystem. 1. Prägnant 2. Aktiv 3. Überprüfbar 4. Verfeinerbar 5. Wertschöpfend 6. Begründbar 7. Deklarativ

20 Folie 20 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Verfeinerung von Zielen 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 Schlecht: Die Benutzung des Systems soll selbsterklärend sein 1. Prägnant 2. Aktiv 3. Überprüfbar 4. Verfeinerbar 5. Wertschöpfend 6. Begründbar 7. Deklarativ

21 Folie 21 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Mehrwertbildung Besser: Das System soll … so dass sich die Nutzer auf andere Aufgaben konzentrieren können Schlecht: Das System soll leicht benutzbar sein. 1. Prägnant 2. Aktiv 3. Überprüfbar 4. Verfeinerbar 5. Wertschöpfend 6. Begründbar 7. Deklarativ

22 Folie 22 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Nachvollziehbare Begründungen Besser: … weil es auch in Mietfahrzeugen einsetzbar sein soll Schlecht: Das System soll auch von ungeschulten Benutzern intuitiv benutzbar sein. 1. Prägnant 2. Aktiv 3. Überprüfbar 4. Verfeinerbar 5. Wertschöpfend 6. Begründbar 7. Deklarativ

23 Folie 23 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme keine Lösungsvorwegnahme Besser: Das System soll um 10% kürzere Antwortzeiten aufweisen als System xy. Schlecht: Durch komprimierte Datenübertragung im Cache soll das geplante System um 10% kürzere Antwortzeiten aufweisen 1. Prägnant 2. Aktiv 3. Überprüfbar 4. Verfeinerbar 5. Wertschöpfend 6. Begründbar 7. Deklarativ

24 Folie 24 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Schablone zur Formulierung von Zielen

25 Folie 25 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme 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

26 Folie 26 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme 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

27 Folie 27 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme 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?

28 Folie 28 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme 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

29 Folie 29 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Szenario als strukturierte Folge von Schritten 1. Der Fahrer schaltet das Navigationssystem ein. 2. Das System ermittelt den aktuellen Standort des Fahrzeugs. 3. Das System erfragt den gewünschten Zielort. 4. Der Fahrer gibt den Zielort in das System ein. 5. Das System ermittelt den benötigten Fartenausschnitt. 6. Das System zeigt die Karte des Zielgebietes am Bildschirm an. 7. Das System erfragt die Optionen für die Routenberechnung. 8. Der Fahrer wählt die Optionen für die Routenberechnung. 9. Das System bestimmt die Wegführung. 10. Das System zeigt eine Erfolgsmeldung am Bildschirm. 11. Das System stellt eine Liste von Wegpunkten zusammen. 12. Das System zeigt den nächsten Wegpunkt der Navigation.

30 Folie 30 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Tabelle

31 Folie 31 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme

32 Folie 32 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme 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)

33 Folie 33 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Sequenz- diagramm

34 Folie 34 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme erweitertes Sequenz- diagramm

35 Folie 35 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Aktivitäts- diagramm

36 Folie 36 H. Schlingloff, SS2011 – modellbasierte Software-Entwicklung eingebetteter Systeme Ziele und Szenarien


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

Ähnliche Präsentationen


Google-Anzeigen