Patterns und Antipatterns in Embedded-Software

Größe: px

Ab Seite anzeigen:

Download "Patterns und Antipatterns in Embedded-Software"

Heike Steinmann
vor 8 Jahren
Abrufe

1 Patterns und Antipatterns in Embedded-Software

2 Zur Person Willi Flühmann Noser Engineering AG 10 Jahre Software-Erfahrung (Deeply)-Embedded- & Windows-Applikationen

3 Inhalt Einführung Besonderheiten bei Embedded-Software Patterns Antipatterns Weiterführende Quellen

4 Was sind Patterns? Problem eines Architekten: Wie gewährleiste ich den Lichteinfall in ein Haus ohne die Wärmeisolation zu gefährden?

5 Was sind Patterns? Mögliche Lösung: Eine rechteckige Öffnung an der Hauswand, ausgefüllt mit zwei Glasscheiben und Luftspalt dazwischen, die mit einem Rahmen fixiert und mit Silikon abgedichtet werden.

6 Was sind Patterns? Mögliche Lösung: Fenster = Pattern

7 Was sind Patterns? Wiederkehrende erfolgreiche Muster, die entdeckt und aufgezeichnet wurden Bewährte Lösungen für bekannte Probleme Gemeinsame Begriffe für die Kommunikation unter Entwicklern

8 Einteilung in der Architektur Aufteilung und Interaktion von Komponenten im Design zusammenhängende Module / Klassen im Code Sprachmittel Code-Fragmente Gruppen von Methoden

9 Einteilung Auch für andere Aspekte: Persistenz verteilte Anwendungen Security usw.

10 Einteilung Auch für andere Aspekte: Persistenz verteilte Anwendungen Security usw.

11 Einteilung für Embedded Aspekte bei Embedded: Ausfallsicherheit Small Memory Nebenläufigkeit, Echtzeit Hardware-Abstraktion usw. mehr dazu später

12 Patterns kritisch betrachten Haben Sie auch schon mal schlechte Erfahrungen gemacht? Übertragung in Sprache C schwierig Zuviel Ballast Observer-Pattern vs. Function-Pointer Singleton-Pattern vs. globale Variablen Dynamische Speicherverwaltung nötig?

13 Antipatterns Bekannte schlechte Lösungen (das Gegenteil) Aus Patterns werden Antipatterns: Übertriebener Einsatz Unpassende Situation

14 Inhalt Einführung Besonderheiten bei Embedded-Software Patterns Antipatterns Weiterführende Quellen

15 Definition Bruce Powel Douglass: A computerized system dedicated to performing a specific set of realworld functions, rather than providing a generalized computing environment.

Eigenschaften Embedded- System Spezialisierung Platzoptimierung Stückkosten reduzieren Fokus auf Kernaufgabe Fertig bei Auslieferung Wartungsfreiheit

16 Eigenschaften Embedded- System Spezialisierung Platzoptimierung Stückkosten reduzieren Fokus auf Kernaufgabe Fertig bei Auslieferung Wartungsfreiheit Massgeschneiderte Hard-/Software Sparsamer Umgang mit Ressourcen Ausfallsicherheit Proprietäres Umfeld Hardwarenahe Software Low Power Small Memory Multitasking Echtzeit

Massgeschneiderte Hard-/Software Sparsamer Umgang mit Ressourcen

17 Unsichtbarkeit der Software und ihrer Struktur Wenn Standard-Betriebssystem verwendet wird: Vollbild-Applikation Splash-Screen während Bootvorgang Betriebssystem-Dialoge unterdrücken(?) Nicht verwendete Funktionalität massregeln / kaschieren Nicht verwendete Funktionalität entfernen

Splash-Screen während Bootvorgang Betriebssystem-Dialoge unterdrücken(?

18 Inhalt Einführung Besonderheiten bei Embedded-Software Patterns Antipatterns Weiterführende Quellen

19 Patterns für Ausfallsicherheit Ausfallsicherheit: Protected Single Channel Homogeneous Redundancy Triple Modular Redundancy Heterogeneous Redundancy Monitor-Actuator Watchdog

20 Patterns für Nebenläufigkeit Scheduling: Round Robin Static Priority Dynamic Priority Vermeidung von Race-Conditions: Critical Section Guarded Call (bzw. Mutex) Rendezvous (bzw. Barrier)

21 Patterns für Nebenläufigkeit Vermeidung von Deadlocks: Ordered Locking Simultaneous Locking Vermeidung von Priority-Inversion: Priority Inheritance Highest Locker Priority Ceiling

22 Patterns für Nebenläufigkeit Inter-Task-Kommunikation: Message Queuing Shared Memory Auf höherem Level: Remote Method Call (bzw. RPC) Data Bus (bzw. Publish-Subscribe)

23 Patterns für Nebenläufigkeit Inter-Task-Kommunikation: Message Queuing Message Queuing Shared-Memory Keine Race-Conditions Einfach zu verifizieren Auf höherem Aufwand Level: für Serialisierung Remote Method Call (RPC) erschwert OO- Data Bus Modellierung (bzw. Publish-Subscribe) Shared Memory Weniger Overhead Schnellere Reaktion Synchronisierung schwieriger (Mutexes, Deadlocks, usw.)

24 Patterns für Nebenläufigkeit Inter-Task-Kommunikation: Message Queuing Shared-Memory Auf höherem Level: Remote Method Call (RPC) Data Bus (bzw. Publish-Subscribe)

25 Patterns für Nebenläufigkeit Inter-Task-Kommunikation: Synchronisierung des Zugriffs auf ein Shared Memory Message Queuing Neben dem offensichtlichen Locking über ein Mutex gibt es Shared-Memory noch viele weitere Varianten mit Vor- und Nachteilen. Folgende Faktoren spielen eine Rolle: Auf höherem Level: optimistisch vs. pessimistisch Remote Method Call (RPC) blockierend vs. nicht-blockierend Data Bus (bzw. Publish-Subscribe) deterministisches Timing (Echtzeit) oder nicht Zugriff aus Interrupt-Kontext oder nicht unidirektionaler vs. bidirektionaler Daten-Transfer

26 Patterns für wenig Speicher Small Architecture: Partial Failure Captain Oates Read-Only Memory (ROM) Hooks

Südpol-Expedition Read-Only geopfert, Memory damit die anderen Hooks besser

27 Patterns für wenig Speicher Small Architecture: Captain Oates Partial Failure Er hat sich als schwächstes Captain Mitglied Oates einer Südpol-Expedition Read-Only geopfert, Memory damit die anderen Hooks besser überleben. Unwichtige Prozesse geben Speicher frei, falls wichtige Prozesse zu wenig haben.

28 Patterns für wenig Speicher Secondary Storage: Application Switching Data Files Resource Files Paging Erfordert Kompromisse bei den Real-Time-Anforderungen

29 Fallbeispiel: Activities in Android Nur die oberste Activity («Screen») existiert. Bei allen anderen bleiben nur die Informationen gespeichert. Beim Drücken des «Back»-Buttons werden die unteren Activities neu erstellt.

30 Patterns für wenig Speicher Memory Allocation: Fixed Allocation Variable Allocation Memory Discard Pooled Allocation Compaction Reference Counting Garbage Collection

31 Patterns für wenig Speicher Small Data Structures: Packed Data Sharing Copy-on-Write Embedded Pointers Compression

32 Inhalt Einführung Besonderheiten bei Embedded-Software Patterns Antipatterns Weiterführende Quellen

33 Antipatterns Typisch für Embedded: Vorzeitige Optimierung(!) Rad neu erfinden («Not invented here»-syndrom) Alles technisch betrachten

34 Antipatterns Zustände vs. Ereignisse: Zu starker Fokus auf Ereignisse statt Zustände Zustandsmaschine anhand Ereignissen strukturieren

35 Fallbeispiel: Strukturierung anhand Ereignissen if (E1) { if (state!= C) { state = B; } } if (E2 && state == B) { state = A; } if (E3 && state == A) { state = C; } schwierig zu vergleichen und zu verifizieren E1 Zustand B Zustand A E3 E2 Zustand C E1 (strukturiert nach den Ereignissen)

36 Antipatterns Unpassende Eigenschaften von Desktop-Software übernehmen: Langer Bootvorgang Software-Komponenten zur Laufzeit laden, zusammensetzen und initialisieren Nicht-deterministische Wartezeiten nach Benutzeraktion Enormer Bedarf an Speicher und Prozessorleistung usw.

37 Antipatterns Unpassende Eigenschaften von Desktop-Software übernehmen: Langer Bootvorgang Software-Komponenten zur Laufzeit laden, zusammensetzen und initialisieren Nicht-deterministische Wartezeiten nach Benutzeraktion Enormer Bedarf an Speicher und Prozessorleistung usw.

38 Inhalt Einführung Besonderheiten bei Embedded-Software Patterns Antipatterns Weiterführende Quellen

39 Embedded-spezifische Patterns Bücher: Small Memory Software Real-Time Design Patterns Design Patterns for Embedded Systems in C

40 Allgemeine Patterns Bücher: GoF-Buch: Design Patterns POSA-Bücher: Pattern Oriented Software Architecture, Volume 1 bis 5 AntiPatterns Internet: Portland Pattern Repository The Hillside Group

41 Fragen? Besuchen Sie unseren Stand:

Ähnliche Dokumente

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se