Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

4.11.2005 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.

Ähnliche Präsentationen


Präsentation zum Thema: "4.11.2005 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt."—  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 Folie 2 H. Schlingloff, Software-Engineering II 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 Folie 3 H. Schlingloff, Software-Engineering II Ü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 Folie 4 H. Schlingloff, Software-Engineering II 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 Folie 5 H. Schlingloff, Software-Engineering II Beispiel aus TSG

6 Folie 6 H. Schlingloff, Software-Engineering II 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 Folie 7 H. Schlingloff, Software-Engineering II 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 Folie 8 H. Schlingloff, Software-Engineering II 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 Folie 9 H. Schlingloff, Software-Engineering II

10 Folie 10 H. Schlingloff, Software-Engineering II 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 Folie 11 H. Schlingloff, Software-Engineering II

12 Folie 12 H. Schlingloff, Software-Engineering II 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 Folie 13 H. Schlingloff, Software-Engineering II 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 Folie 14 H. Schlingloff, Software-Engineering II abstrakte Anwendungsfälle, Pakete

15 Folie 15 H. Schlingloff, Software-Engineering II 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 Folie 16 H. Schlingloff, Software-Engineering II 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 Folie 17 H. Schlingloff, Software-Engineering II Beispiel (1) Name des Anwendungsfalls 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 Folie 18 H. Schlingloff, Software-Engineering II Beispiel (2) Vorbedingung: 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 Folie 19 H. Schlingloff, Software-Engineering II Beispiel (3) Systemzustand im Fehlerfall: 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 Folie 20 H. Schlingloff, Software-Engineering II 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 Folie 21 H. Schlingloff, Software-Engineering II 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 Folie 22 H. Schlingloff, Software-Engineering II

23 Folie 23 H. Schlingloff, Software-Engineering II Pause!

24 Folie 24 H. Schlingloff, Software-Engineering II Pause!

25 Folie 25 H. Schlingloff, Software-Engineering II 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 Folie 26 H. Schlingloff, Software-Engineering II StateCharts UML-Verhaltenszustandsautomaten (Zustandsdiagramme)

27 Folie 27 H. Schlingloff, Software-Engineering II 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 Folie 28 H. Schlingloff, Software-Engineering II 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 Folie 29 H. Schlingloff, Software-Engineering II 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 Folie 30 H. Schlingloff, Software-Engineering II 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 Folie 31 H. Schlingloff, Software-Engineering II

32 Folie 32 H. Schlingloff, Software-Engineering II 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 Folie 33 H. Schlingloff, Software-Engineering II 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 Folie 34 H. Schlingloff, Software-Engineering II 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 Folie 35 H. Schlingloff, Software-Engineering II 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 Folie 36 H. Schlingloff, Software-Engineering II Schritt 7: Verfeinern der Systemreaktion Parallelität zur visuellen Erkennung von Reaktionen

37 Folie 37 H. Schlingloff, Software-Engineering II Ergebnis


Herunterladen ppt "4.11.2005 Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt."

Ähnliche Präsentationen


Google-Anzeigen