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 4.11.2005

vorläufige Vorlesungsplanung Fr. 21.10. Einleitungsbeispiel Mi. 26.10. Definitionen Fr. 28.10. Realzeit Mi. 2.11. Anforderungsanalyse 1 Fr. 4.11. Anforderungsanalyse 2 Mi. 9.11. Anwendungsfallbeschreibungen Fr. 11.11. Modellierung 1 (Automaten) Mi. 16.11. Modellierung 2 (UML, Simulink) Fr. 18.11. Architekturen für eingebettete Systeme Mi. 23.11. Steuerung und Ablaufplanung, SPS Fr. 25.11. ----- ENTFÄLLT Mi. 30.11. Echtzeitbetriebssysteme und Middleware Fr. 2.12. ----- ENTFÄLLT Mi. 7.12. Fehlertoleranz und Ausfallsicherheit Fr. 9.12. Hardware/Software Co-Design Mi. 14.12. Automotive Software Engineering 1 Fr. 16.12. Automotive Software Engineering 2 Mi. 21.12. Produktlinienentwicklung 4.11.2005

Ü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.11.2005

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, Retschitzegger:UML@Work http://www.big.tuwien.ac.at/teaching/offer/ws05/mtm_vo/umlKap4_1-37_Anwendungsfalldiagramm.pdf 4.11.2005

Beispiel aus TSG 4.11.2005

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 4.11.2005

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 4.11.2005

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

4.11.2005

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) 4.11.2005

4.11.2005

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 4.11.2005

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 4.11.2005

abstrakte Anwendungsfälle, Pakete 4.11.2005

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? 4.11.2005

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] 4.11.2005

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. 4.11.2005

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. 4.11.2005

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) E-Mail-System (sekundärer Akteur) Fax-System (sekundärer Akteur) Trigger: keine 4.11.2005

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) 4.11.2005

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. 4.11.2005

4.11.2005

Pause! 4.11.2005

Pause! 4.11.2005

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. 086.02/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) 4.11.2005

StateCharts UML-Verhaltenszustandsautomaten (Zustandsdiagramme) 4.11.2005

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 4.11.2005

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 4.11.2005

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 3.1.1 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 … 4.11.2005

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. 4.11.2005

4.11.2005

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 4.11.2005

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 4.11.2005

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) 4.11.2005

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 4.11.2005

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

Ergebnis 4.11.2005