Kernprozess zur System- und Software- Entwicklung

Transkript

1 Analyse der Benutzeranforderungen & Spezifikation der logischen Systemarchitektur Kernprozess zur System- und Software- Entwicklung Anwendungsfälle Testergebnisse Akzeptanztest & Systemtest Analyse der logischen Systemarchitektur & Spezifikation der technischen Systemarchitektur Testfälle Testergebnisse Kalibrierung Integrationstest des Systems Integration der Systemkomponenten Analyse der Software-Anforderungen & Spezifikation der Software-Architektur Spezifikation der Software-Komponenten Design & Implementierung der Software-Komponenten Testfälle Testergebnisse Integrationstest der Software Integration der Software-Komponenten Test der Software- Komponenten 1 J. Schäuffele, Th. Zurawka:, Vieweg, 2003 Spezifikation der Software-Architektur und der Software-Komponenten! objektorientierte Modellierung der Software-Architektur! Schnittstellen als öffentliche Methoden 2

2 Beispiel: Berechnung von Raddrehzahl und Fahrzeuggeschwindigkeit beim ABS Aggregationsbeziehung Klasse: Fahrzeug Attribute: Geschwindigkeit v Gangstufe g Methoden: compute_v() compute_g() Klasse: Rad Attribute: Drehzahl n Klasse: Motor Attribute: Drehzahl n Methoden: init_n() compute_n() out_n() J. Schäuffele, Th. Zurawka:, Vieweg, 2003 Methoden: init_n() compute_n() out_n() 3 Grafische Darstellung der Software-Architektur mit Objektdiagrammen Modul Funktion_f1 Objekt Fahrzeug_1: Fahrzeug Objekt Rad_v_r: Rad Objekt Rad_v_l: Rad Objekt Rad_h_r: Rad Objekt Rad_h_l: Rad Objekt Motor_1: Motor J. Schäuffele, Th. Zurawka:, Vieweg,

3 Spezifikation der Schnittstellen zum Echtzeitbetriebssystem mit Modulen! Module: Software-Komponenten auf der obersten Hierarchieebene einer Funktion! Schnittstellen zum Echtzeitbetriebssystem (Prozesse)! Schnittstellen zum Kommunikationssystem (Messages) Messages Prozesse P 1... P m M 1... M n Empfangs- Messages Modul Sende- Messages J. Schäuffele, Th. Zurawka:, Vieweg, Spezifikation von wiederverwendbaren Software-Komponenten mit Klassen Methode m 1 Methoden m 1... m k Argumente Objekt: Klasse Rückgabewerte J. Schäuffele, Th. Zurawka:, Vieweg,

4 Grafische Darstellung der Software-Architektur mit Blockdiagrammen Modul Funktion_f1 Objekt Rad_v_r: Rad Objekt Rad_v_l: Rad Objekt Fahrzeug_1: Fahrzeug Objekt Rad_h_r: Rad Objekt Rad_h_l: Rad Objekt Motor_1: Motor J. Schäuffele, Th. Zurawka:, Vieweg, Spezifikation der Software-Architektur für einen Mikrocontroller Software-Komponenten Schnittstellen Anforderungen Testergebnisse Spezifikation einer Software-Komponente Datenmodell Verhaltensmodell Echtzeitmodell Spezifikation einer Software-Komponente Testfälle (Spezifikation) J. Schäuffele, Th. Zurawka:, Vieweg,

5 Spezifikation des Verhaltensmodells! Blockdiagramme! Entscheidungstabellen! Zustandsautomaten! mit Programmiersprachen 9 Kontrollfluss zur Festlegung der Ausführungsreihenfolge in ASCET-SD Boolesche Anweisung Arithmetische Anweisung J. Schäuffele, Th. Zurawka:, Vieweg,

6 Spezifikation komplexer Algorithmen mit Blockdiagrammen! arithmetische Funktionen Beispiel: Integrationsverfahren nach Euler! boolsche Funktionen 11 Integrationsverfahren nach Euler f(t) Zeit t F( t ) F t n = f ( t) dt n t0 n 1 * ( tn) = ( ti+ 1 i i= 0 i ( ti 1 ti) dt t 0 t 1 t 2 t 3 t 4 t 5 durch t )* f ( t ) = + (Schrittweite) Inkrementelle Berechnung: * * F ( t ) = F ( t ) + dt i+ 1 i i i approximiert * f ( t ) i 12

7 Software-Komponenten für die Integration nach Euler! F * (t i+1 ) = F * (t i ) + dt i f(t i )! Eingangsgröße mit Konstante K gewichtbar! Wert durch Schranken MX (MN) nach oben (unten) begrenzt! Methode compute() berechnet memory(t i+1 ) = memory(t i ) + K dt in(t i ) und berücksichtigt Schranken! dt vom Echtzeitbetriebsystem für jede Task bereitgestellt! Methode out() : aktueller Integrationswert! Methode init() : Initialisierung mit IV! Methoden init() bzw. compute() in Abhängigkeit von boolschen Ausdrücken I und E 13 Spezifikation der Klasse Integrator als Blockdiagramm in ASCET-SD memory(ti+1) = memory(ti) + K dt in(ti) J. Schäuffele, Th. Zurawka:, Vieweg,

8 Außenansicht der Klasse Integrator in ASECT-SD in return/out J. Schäuffele, Th. Zurawka:, Vieweg, Spezifikation Boolscher Ausdrücke als Blockdiagramm in ASCET-SD J. Schäuffele, Th. Zurawka:, Vieweg,

9 Spezifikation des Verhaltensmodells! Blockdiagramme! Entscheidungstabellen! Zustandsautomaten! mit Programmiersprachen 17 Spezifikation Boolscher Ausdrücke als Entscheidungstabelle Regeln X1 X2 X3 Y1 Y2 R R R R R R R R Bedingungen Aktionen J. Schäuffele, Th. Zurawka:, Vieweg,

10 Optimierung der Entscheidungstabelle Relevante Regeln X1 X2 X3 Y1 Y2 R R R Bedingungen Aktionen J. Schäuffele, Th. Zurawka:, Vieweg, Optimierung der Entscheidungstabelle für Aktion Y2 Relevante Regeln X1 X2 X3 Y2 R R7 1 1 * 1 R8 1 1 * 1 Bedingungen Aktion J. Schäuffele, Th. Zurawka:, Vieweg,

11 Sequenzielle Verknüpfung von Entscheidungstabellen X1 X2 X3 Entscheidungstabelle 1 X4 X5 X6 X7 Entscheidungstabelle 2 Entscheidungstabelle 3 Y1 Y2 Y3 Y4 J. Schäuffele, Th. Zurawka:, Vieweg, Spezifikation des Verhaltensmodells! Blockdiagramme! Entscheidungstabellen! Zustandsautomaten! mit Programmiersprachen 22

12 Beispiel: Ansteuerung der Tankreservelampe! Füllstandsgeber: misst Tankinhalt und liefert Analogsignal zwischen 0V und 10V, zeit- und wertdiskret abgetastet! 10V = leerer Tank, 0V = voller Tank, 8,5V = Reservestand 5L, Lampe muss eingeschaltet werden! Lampe soll erst bei mehr als 6l Füllstand (= 8V) ausgeschaltet werden Signalwert > 8,5 V Lampe Aus Lampe Ein Signalwert < 8,0 V J. Schäuffele, Th. Zurawka:, Vieweg, Zuordnung von Aktionen und Definition des Startzustands C 2 : Signalwert > 8,5 V A 2 : Lampe einschalten Funktionskontrolle A S :Lampe einschalten (S) C 0 : Zeitspanne > 2 s Lampe Aus Lampe Ein C 1 : Signalwert < 8,0 V A 1 : Lampe ausschalten Legende: C i : Bedingung (engl. Condition) A i : Aktion (engl. Action) (S): Startzustand (engl. Start State) J. Schäuffele, Th. Zurawka:, Vieweg,

13 Statecharts Entstanden durch Erweiterung des Konzepts der Transitionssysteme! Parallelität, explizite Auswahl! hierarchische Modellierung in UML: Zustandsdiagramme Graphische Notation für den Systementwurf mit formaler Semantik Tools! Statemate (1990)! Rhapsody (Anpassung UML)! Editor, Dokumentation! Simulation! Analyse! Code Synthese 25 Ereignisse UML: An event is the specification of a significant occurrence that has a location in time and space. Z.B.: Signale, Verstreichen eines Zeitpunktes, Zustandsübergang, Aufruf einer Operation Ereignisse als Auslöser (Trigger) von Transitionen. Damit Verknüpfung mehrerer Verhaltensbeschreibungen (Objekte, Systemteile) durch externe Ereignisse möglich. Transitionsbeschriftungen: Trigger/Aktion Aktionen können Ereignisse erzeugen! 26

14 Trennung von Kommunikation und Aktionen! Kommunikation durch Trigger für Transitionen! Ausführung von Aktivitäten als Aktionen (die jedoch andere Transitionen triggern können). Wir unterscheiden:! externe Ereignisse von außerhalb des modellierten Systemteils! interne Ereignisse von Quellen innerhalb des modellierten Systemteils 27 Condition connector [C 1 ]/A 1 E C.. [C n ]/A n Ereignis Aktion, optional 28

15 Hierarchische Zustände (Zustandsverfeinerung) P Q Unterzustände R or - Zustand Interpretation Wenn das System im Zustand P ist, dann ist es entweder im Unterzustand Q oder im Unterzustand R. 29 Hierarchische Zustände (Zustandsverfeinerung) P Q R Transitionen! zwischen Unterzuständen 30

16 Hierarchische Zustände (Zustandsverfeinerung) P Q R Transitionen! zwischen Unterzuständen! in Unterzustände oder von Unterzuständen 31 Hierarchische Zustände (Zustandsverfeinerung) P Q RESET R Transitionen! zwischen Unterzuständen! in Unterzustände oder von Unterzuständen! aus dem or - Zustand 32

17 Hierarchische Zustände (Zustandsverfeinerung) Default - Transition Default - Unterzustand ENTER P Q RESET R Transitionen! zwischen Unterzuständen! in Unterzustände oder von Unterzuständen! aus dem or Zustand! in den or - Zustand 33 Syntax Statecharts (bisher) Zustand Transition E [C] / A Ereignis Bedingung Aktion Default-Transition Default-Unterzustand 34

18 Syntax Statecharts (bisher) [C 1 ]/A 1 or Konnektor E C.. [C n ]/A n P Q or - Zustand. R 35 Orthogonalität in Statecharts diese Notation ist jetzt notwendig Q R P kennzeichnet and - Zustände Ein and Zustand besteht aus zwei oder mehr orthogonalen Komponenten. 36

19 Orthogonalität in Statecharts P Q R Interpretation! In einem and Zustand zu sein bedeutet, sich simultan in allen seinen Komponenten zu befinden.! Hier: Wenn das System im Zustand P ist, dann ist es gleichzeitig auch in Q und in R.! Die Unterzustände eines and Zustands werden orthogonale Komponenten genannt.! Werden wie alle übrigen Zustände behandelt (Unterzustände, Transitionen, ). 37 Orthogonalität in Statecharts P Q Q 1 Q 2 R R 1 R 2 In einem and Zustand befinden wir uns in einem Unterzustand jeder orthogonalen Komponente.! Wenn in P, dann in Q und in R und in einem der folgenden Zustandspaare: (Q 1, R 1 ), (Q 1, R 2 ), (Q 2, R 1 ), (Q 2, R 2 ) 38

20 Orthogonalität in Statecharts P Q Q 1 Q 2 R R 1 R 2 Transitionen! Einen and Zustand durch eine Transition auf die Grenze zu betreten bedeutet, alle orthogonalen Komponenten gleichzeitig durch die default Transition zu betreten. 39 Orthogonalität in Statecharts P Q Q 1 Q 2 R R 1 R 2 Transitionen! Einen and Zustand durch eine Transition auf die Grenze zu betreten bedeutet, alle orthogonalen Komponenten gleichzeitig durch die default Transition zu betreten.! Einen and Zustand durch eine Transition von der Grenze zu verlassen bedeutet, alle orthogonalen Komponenten gleichzeitig zu verlassen. 40

21 and Zustand durch Einzeltransition betreten P S0 G Q S1 S2 R S3 S4 Wenn G eintritt, im Zustand S geht das System in {S1, S3} (Default-Transitionen in Q sind unwirksam). 41 and Zustand durch Einzeltransition verlassen P Q S1 S2 E S0 R S3 S4 Wenn E eintritt und die Komponente Q im Zustand S2 ist, wird der and Zustand verlassen (egal in welchem Zustand die untere Komponente ist). Entweder das System in ein einem and-zustand, dann gleichzeitig in einem Tupel von Unterzuständen, für jede Komponente eine, oder es außerhalb des and-zustandes. 42

22 fork- und join- Transitionen S E E 1 /A 1 Q 1 Q 2 E T E 2 /A 2 R 1 R 2 Eine fork Transition findet statt, wenn alle ihre Ereignisse vorliegen. Alle ihre Aktionen werden dann ausgeführt. Entsprechend: join Transition. Wenn E stattfindet und das System in der Basiskonfiguration {Q 1, R 2 } ist, dann geht es in T über. 43 Zustandsautomaten mit Entry- und exit- Aktionen, sowie static Reactions C 1 C 2 A 1 A 1 C 1 C 2 Zustand X Zustand X Entry-Aktion: A 1 Static-Aktion: -- C 3 A 2 C 4 A 2 C 3 C 4 Exit-Aktion: A 2 J. Schäuffele, Th. Zurawka:, Vieweg,

23 Deterministische Zustandsautomaten durch Vergabe von Prioritäten C 1 C 1 Zustand X Zustand X C 2 C 2 A 1 A 2 C 3 A 3 Priorität: C 2 (1) (3) (2) C 2 A 1 A 2 C 3 A 3 J. Schäuffele, Th. Zurawka:, Vieweg, Stateflow von The MathWorks! Regionen! Regionnr.! Action-Guard 46

24 Stateflow vs. Statecharts! Begrenzte Menge an Zuständen! OR-Zustände und AND-Zustände! Junction-Konnektor! Shallow History! Keine Synchronisationselemente! Offene Hierarchie (keine Verschachtelung von Statecharts)! Keine internen Befehle(z.B. in state)! Kombination von Ereignissen und negative Ereignisse nicht möglich! Prioritätenreihenfolge von oben nach unten! Prioritätenauswertung im gleichen Zustand nach der 12 Uhr Regel! Action Condition! Run-to-completion-step (Schritt ist nicht unterbrechbar)! Zeit vergeht nur in einem stabilen Zustand! Pseudo-Parallelität (kleinste Regionnummer wird als erstes abgearbeitet) 47 ASCET-SD von ETAS! Prioritäten! Startzustand! Trigger-Ereignisse! Hierarchie! Historyzustand 48

25 ASCET-SD vs. Statecharts! Begrenzte Menge an Zuständen! OR-Zustände! Junction-Konnektor! Shallow History! Keine nebenläufigen Abläufe! Offene und geschlossene Hierarchie! Keine internen Befehle (z.b. in state)! Kombination von Ereignisse und negative Ereignisse nicht möglich! Prioritätenreihenfolge von oben nach unten! Prioritätenauswertung durch explizite Prioritätenvergabe! Schalten nur durch Trigger-Ereignisse (zyklisch)! Run-to-completion-step (Schritt ist nicht unterbrechbar)! Zeit vergeht nur in einem stabilen Zustand 49 Spezifikation des Verhaltensmodells! Blockdiagramme! Entscheidungstabellen! Zustandsautomaten! mit Programmiersprachen 50

26 Software-Komponenten für die Integration nach Euler! F * (t i+1 ) = F * (t i ) + dt i f(t i )! Eingangsgröße mit Konstante K gewichtbar! Wert durch Schranken MX (MN) nach oben (unten) begrenzt! Methode compute() berechnet memory(t i+1 ) = memory(t i ) + K dt in(t i ) und berücksichtigt Schranken! dt vom Echtzeitbetriebsystem für jede Task bereitgestellt! Methode out() : aktueller Integrationswert! Methode init() : Initialisierung mit IV! Methoden init() bzw. compute() in Abhängigkeit von boolschen Ausdrücken I und E 51 Spezifikation der Klasse Integrator als Blockdiagramm in ASCET-SD memory(ti+1) = memory(ti) + K dt in(ti) J. Schäuffele, Th. Zurawka:, Vieweg,

27 Spezifikation der Methoden der Klasse Integrator in der Sprache C /* Statische Variablen*/ extern real64 memory; extern real64 dt; /*methode compute() */ void compute (real64 in, real64 K, real64 MN, real64 MX, sint8 E) { real64 temp_1; } if E { } temp_1 = memory + in * (K * dt); if (temp_1 > MX) { temp_1 = MX;} if (temp_1 < MN) { temp_1 = MN;} memory = temp_1; /* Methode out() */ real64 out (void) { return (memory); } /* Methode init() */ void init (real64 IV, sin8 I) { if I{ memory = IV; } } 53 Spezifikation einer Software-Komponente Testergebnisse Design & Implementierung einer Software-Komponente Datenmodell (Variablen & Parameter) Verhaltensmodell Echtzeitmodell Design einer Software-Komponente Implementierung einer Software-Komponente (z.b. Quellcode) Testfälle (Design) J. Schäuffele, Th. Zurawka:, Vieweg,

28 Spezifikation des Echtzeitmodells! Konfiguration des Echtzeitbetriebssystems! Betriebszustände, Übergänge, Übergangsbedingungen! Zuteilungsstrategie und Task-Prozess-Liste für jeden Betriebszustand, Initialisierungs- und wiederkehrende Prozesse! Basis: Prozess- und Message-Schnittstellen der Module 55 Validation der Spezifikation! Simulation Nachbildung und Ausführung einer Software-Funktion auf einem Rechner! Rapid Prototyping Ausführung einer Software-Funktion auf einem Rechner mit Schnittstelle zum Fahrzeug (Experimentiersystem)! Modelle als Basis: Modell-Compiler 56

29 Aufbau von rapid-prototyping-werkzeugen Modellierwerkzeug Rapid-Prototyping-Werkzeug Modell der Software- Funktionen Modell-Compiler Quellcode- Assemblercode-Module Komponente Compiler-Tool-Set Experimentierwerkzeug Experimentiersystem Programmstand Datenstand Download- Werkzeug Flash-Programmierwerkzeug J. Schäuffele, Th. Zurawka:, Vieweg, 2003 Experimentiersystem mit ausführbarem Programm- & Datenstand Experimentiersystem 57 Simulation! Software-Funktionen! Zusammenspiel mit der Umgebung (Sollwertgeber, Sensoren, Aktuatoren, Strecke)! virtuelles Fahrzeug-, Fahrer- und Umweltmodell! virtuelles Steuerungsgeräte- und Software-Modell! Ausführung auf Simulationssystem: Model-in-the-loop-Simulation 58

30 Rapid Prototyping! Prototyp: technisches Modell eines neuen Produkts! Software-Prototyp: zeigt Software-Funktionen im praktischen Einsatz 59