Prof. Dr. Holger Schlingloff

Präsentation zum Thema: "Prof. Dr. Holger Schlingloff"—  Präsentation transkript:

1 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement
Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik

2 vorläufige Vorlesungsplanung
Fr Einleitungsbeispiel Mi Definitionen Fr Realzeit Mi Anforderungsanalyse 1 Fr Anforderungsanalyse 2 Mi Anwendungsfallbeschreibungen Fr Modellierung 1 (Automaten) Mi Modellierung 2 (UML, Simulink) Fr Architekturen für eingebettete Systeme Mi Steuerung und Ablaufplanung, SPS Fr ENTFÄLLT Mi Echtzeitbetriebssysteme und Middleware Fr ENTFÄLLT Mi Fehlertoleranz und Ausfallsicherheit Fr Hardware/Software Co-Design Mi Automotive Software Engineering 1 Fr Automotive Software Engineering 2 Mi Produktlinienentwicklung

3 Übersicht 0. Einleitungsbeispiel (Mars Polar Lander)
1. Eingebettete Systeme 1.1. Definitionen (eingebettetes System, Realzeit, Prozess, Steuerung, …) 1.2. Anforderungsanalyse allgemeine Vorgehensweise Beispiel Türsteuergerät systematische Ansätze; Def. Modus, Kondition, Historie Anwendungsfallbeschreibungen

4 Anwendungsfallbeschreibungen
Anwendungsfalldiagramme („Use Cases“) UML Notation zur Beschreibung von Systemverhalten spezifiziert (Namen von) Akteure und Aktionen im System sowie deren Aufrufbeziehung Ablauf der Aktionen wird schablonenartig anhand konkreter Szenarien beschrieben (textuell oder mit Sequenz- oder Aktivitätsdiagrammen) Funktionale Zerlegung des zu entwickelnden Systems in Aktionen („Anwendungsfälle) und in Akteure Anwendungsfälle repräsentieren die Anforderungen der Kunden Akteure interagieren mit dem System im Kontext der Anwendungsfälle © Material für diese Vorlesungsstunde: Lit.: Hitz, Kappel, Kapsammer,

5 Beispiel aus TSG

6 Akteure Akteure interagieren mit dem System
indem sie das System benutzen, d.h. die Ausführung von Anwendungsfällen initiieren (aktiv) indem sie vom System benutzt werden, d.h. Funktionalität zur Realisierung von Anwendungsfällen zur Verfügung stellen (passiv) Akteur wird durch Assoziationen mit Anwendungsfällen verbunden – »kommuniziert« dadurch mit dem System die Assoziation ist binär und kann Multiplizitäten aufweisen Akteure repräsentieren Rollen konkrete Benutzer können gleichzeitig mehrere Rollen annehmen menschliche und automatische Akteure (z.B. Mail-System, andere Steuergeräte) Ein Akteur ist ein Classifier, verfügt über Klasseneigenschaften

7 Aktionen Anwendungsfälle (use cases) beschreiben das Verhalten, das von dem zu entwickelnden System erwartet wird Identifizierung z.B. durch Sammeln von Kundenwünschen und Analyse der textuellen Problemstellung Classifier, kann wiederum einem Classifier zugeordnet werden Ablauf der Anwendungsfälle kann textuell als Notiz beschrieben werden

8 Beziehungen zwischen Anwendungsfällen (1)
«include» Das Verhalten des benutzten Anwendungsfalls (inkludierter Anwendungsfall) wird in den benutzenden Anwendungsfall (Basis-Anwendungsfall) eingebunden Vergleichbar Unterprogramm-Aufruf

9

10 Beziehungen zwischen Anwendungsfällen (2)
«extend» B ist eine Verallgemeinerung von A, und A ist ein Spezialfall von B Das Verhalten von B kann in A inkludiert werden, und B kann von A aktiviert werden (muss aber nicht)

11

12 mehrfache Erweiterungen bzw. Spezialisierungen möglich
Angabe des »Wo« durch Erweiterungsstellen in A Angabe des »Wann« durch Bedingung in A bzw. als Teil der «extend»-Beziehung

13 Beziehungen zwischen Anwendungsfällen (3)
Generalisierung von Aktionen Vergleichbar mit Generalisierungsbeziehung (Vererbungsrelation) zwischen Klassen B erbt Verhalten von A und kann dieses überschreiben oder ergänzen B erbt alle Beziehungen von A Auch für Akteure möglich

14 abstrakte Anwendungsfälle, Pakete

15 Identifikation von Akteuren und Aktionen
Akteure: Subjekte in den Anforderungen Wer benutzt die wesentlichen Anwendungsfälle? Wer braucht Systemunterstützung für die tägliche Arbeit? Wer ist für die Systemadministration zuständig? Wer oder was interessiert sich für die Ergebnisse des Systems? Mit welchen externen Geräten / (Software-) Systemen muss das System kommunizieren können? Anwendungsfälle: Verben in den Anforderungen Welche Tätigkeiten sollen die Akteure durchführen? Welche Funktionalität soll das System bereit stellen? Welche Schnittstellen benutzen andere Systeme/Geräte? Beziehungen: Bedingungen und Verweise Welche Aktivitäten sind voneinander abhängig? Welche gemeinsamen Teile gibt es? Welche Spezialfälle treten auf? Was ist enthalten?

16 Anwendungsfallbeschreibung
Als Tabelle / strukturierter Text notiert: Name des Anwendungsfalls Ziel: Kurzbeschreibung der Funktionalität Vorbedingungen: Voraussetzung für erfolgreiche Ausführung Nachbedingungen: Systemzustand nach erfolgreicher Ausführung Fehlersituationen für diesen Problembereich, sowie Systemzustand im Fehlerfall (nach Ablauf) Akteure, die mit dem Anwendungsfall kommunizieren Trigger: Auslösende Ereignisse für den Anwendungsfall Standardablauf: einzelne Schritte / andere Anwendungsfälle Alternativabläufe: Abweichungen vom Standardablauf [nach A. Cockburn: Goals and Use Cases. Journal of Object-Oriented Programming, Sept. 1997]

17 Beispiel (1) Name des Anwendungsfalls Kurzbeschreibung
„Termin erfassen“ Kurzbeschreibung Ein Termin kann für einen oder mehrere Teilnehmer von dazu berechtigten Benutzern (müssen nicht notwendigerweise auch Teilnehmer sein) erfasst werden. Alle Teilnehmer müssen über diesen neuen Termin verständigt werden. Neue Termine müssen sofort in allen geöffneten, die jeweiligen Teilnehmer betreffenden Kalendern nachgezogen werden.

18 Beispiel (2) Vorbedingung: Nachbedingung: Fehlersituationen:
Benutzer ist dem System bekannt. Nachbedingung: Neuer Termin ist erfasst. Alle Teilnehmer sind verständigt und gegebenenfalls informiert, dass es aus Berechtigungsgründen nicht möglich war, ihren Terminkalender zu verändern. Alle Sichten sind aktualisiert. Fehlersituationen: Benutzer hat für keinen der Teilnehmer die Berechtigung, den Termin zu erfassen, d.h. im Kalender des Teilnehmers einzutragen.

19 Beispiel (3) Systemzustand im Fehlerfall: Akteure: Trigger:
Termin konnte nicht erfasst werden. Terminkalender der Teilnehmer und alle Sichten darauf sind im Status quo ante. Akteure: Benutzer (primärer Akteur) -System (sekundärer Akteur) Fax-System (sekundärer Akteur) Trigger: keine

20 Beispiel (4) Standardablauf: (1) Benutzer identifiziert sich.
(2) Daten des neuen Termins (Zeit, Ort, vorauss. Dauer, Teilnehmer, etc.) werden eingegeben. (3) Benutzer ist berechtigt, für alle Teilnehmer den Termin zu erfassen. (4) Termin führt bei keinem Teilnehmer zu Kollisionen und wird erzeugt. (5) Alle Teilnehmer (ausgenommen der Benutzer, wenn dieser auch Teilnehmer ist) werden gemäß ihrer bevorzugten Kommunikationsart verständigt. («include» Teilnehmer verständigen) (6) Alle geöffneten Kalender von Teilnehmern werden aktualisiert («include» Kalender aktualisieren)

21 Beispiel (5) Alternativablauf:
(3’) Benutzer ist für mindestens einen Teilnehmer nicht berechtigt, den Termin in seinem Kalender zu erfassen. (4’) Analog zu (4) (5’) Analog zu (5), wobei jene Teilnehmer, deren Kalender nicht änderbar waren, zusätzlich davon informiert werden, dass es aus Berechtigungsgründen nicht möglich war, ihren Terminkalender zu verändern. (6’) Alle geöffneten Kalender von jenen Teilnehmern werden aktualisiert, für die eine Berechtigung zur Änderung des Kalenders vorliegt.

22

23 Pause!

24 Pause!

25 Weiterverarbeitung von Use Cases
C. Denger, D. Kerkow, A. v.Knethen, M. Mora, B. Paech: Von Use Cases zu Statecharts in 7 Schritten. IESE-Report Nr /D (Dez. 2002) (LESEN!) M. Friske, H. Schlingloff: Von Use Cases zu Test Cases: Eine systematische Vorgehensweise; In: MBEES - Model Based Engineering of Embedded Systems Dagstuhl (Jan. 2005)

26 StateCharts UML-Verhaltenszustandsautomaten (Zustandsdiagramme)

27 Von UseCases zu StateCharts in 7 Schritten
0. Vorbereitung: Identifikation der relevanten Elemente (Variablen etc.) aus dem Lastenheft Tabelle monitorierter und kontrollierter Größen mit Wertebereichen und Anfangswerten Liste der Akteure und UCs Gruppierung der UC in Klassen sowie Identifikation von UC-Beziehungen Abstraktion von Variablen und UCs

28 Schritt 1: Festlegung Package-Struktur
für jeden Funktionsblock des Systemlastenhefts ein Package die Package-Struktur des Systems verdeutlicht die vom System realisierten Funktionsblöcke im Beispiel Sitzsteuerung, Fenstersteuerung, Außenspiegeleinstellung, Türschloss, Innenraumbeleuchtung

29 Schritt 2: Erstellung des Klassendiagramms
eine Umgebungsklasse ein Klassendiagramm pro Funktionsblock 1.) eine Inputklasse vom Typ „Aktor_Name_Input“ für jeden Aktor 2.) je eine Klasse für jede monitorierte Größe der UCs eines Funktionsblocks, die nicht einem Aktor der Umgebung zugeordnet sind 3.) ebenso für alle kontrollierten Größen der UCs eines Funktionsblocks 4.) eine Klasse für jeden in identifizierten UCs des Funktionsblocks 5.) eine Timer-Klasse Im Beispiel: theUC_Stelle_Eigene_Ein:UC_Stelle_Eigene_Ein the_UC_Stelle_Andere_Ein:UC_Stelle_Andere_Ein theUC_Total:UC_Stelle_Total_Ein theM_Font_Input:M_Font_Insassen_Input theM_Fensterposition_Ist:M_Fenster_Position_Ist theC_Fenster_Position:C_Fenster_Position_Soll …

30 Assoziationen zwischen den verschiedenen Klassen
Eine Klasse einer monitorierten Größe hat immer eine bidirektionale Assoziation zu den UC Klassen, die diese Größe als Eingang benötigen. Eine UC Klasse hat immer eine gerichtete Assoziation zu den Klassen der von diesem UC kontrollierten Größen Eine UC Klasse hat eine bidirektionale Assoziation zu einer anderen UC Klasse, wenn sich die beiden UCs, die durch die Klassen repräsentiert werden, gegenseitig unterbrechen. Eine UC Klasse hat eine gerichtete Assoziation zu den Klassen der von diesem UC unterbrochenen UCs. Eine UC Klasse hat eine bidirektionale Assoziation zu einer anderen UC Klasse, wenn zwischen den entsprechenden UCs eine „Includes“-Beziehung besteht. Eine UC Klasse hat eine Vererbungsbeziehung zu einer anderen UC Klasse, wenn zwischen den entsprechenden UCs eine „Extends“- Beziehung besteht.

31

32 Schritt 3: Modellierung interner Größen
mögliche Werte der internen Größen als Attribute der Klassen, die diese Größen repräsentieren z.B. diskrete Variable „a_Speicher_Position“, für kontinuierliche Größe „Gespeicherte Sitzposition“ Vgl. Modell der vier Variablen

33 Schritt 4: SC der monitorierten Größen
ein SC für jede Klasse monitorierter Größen aus dem Klassendiagramm jeder mögliche Wert der monitorierten Größe als State Transitionen als Zustandsübergänge zwischen den States ausgelöst durch Umgebungsaktivitäten

34 Schritt 5: SC der kontrollierten Größen
analog zur Modellierung der monitorierten Größen Unterschied: Ableitung der Events aus Aktivitäten, deren Subjekt das modellierte System selbst ist (Aktor nicht aus der Umgebung des modellierten Systems, sondern das System oder ein Teilsystem)

35 Schritt 6: Use Case Statecharts
Erstellung der SCs für die UC-Klassen ein SC für jede Klasse aus dem Klassendiagramm, die einen UC repräsentiert Modellierung der Ausnahmefälle der UC Ausnahmefälle, die zu anderen Use Cases führen Ausnahmefälle, die die Durchführung eines UC (-Schrittes) verhindern Ausnahmefälle, die zum Abbruch der Systemreaktion führen

36 Schritt 7: Verfeinern der Systemreaktion
Parallelität zur visuellen Erkennung von Reaktionen

37 Ergebnis