Rhapsody in C ein System zur aspektorientierten Embedded- Entwicklung? Dr.- Ing. Alexander Steinkogler B. Braun Melsungen AG
Einführung Was sind Aspekte? Anforderungen: Thema / Aspekt Berühren viele andere Anforderungen Auf verschiedenen Abstraktionsebenen Beispiele: Logging / Tracing Memory-Management & Caching-Strategien Fehlerbehandlung & Sicherheit Prüfung aller Pointer-Eingangsvariablen auf NULL
Aspekte und verteilter Code PKG_Display PKG_Controller Memory Memory Memory Memory Software
Ziel der aspektorientierten Programmierung (AOP) Vermeidung von verteiltem Code für einen Aspekt PKG_Controller PKG_Display Aspect_Memory Software
Beispiel: Programmierung eines begrenzten Puffers Hauptprogramm R1: Der Puffer hat eine begrenzte Kapazität R2: Auf den Puffer kann mit Put() und Get() zugegriffen werden R3: Der Puffer blockiert Get()-Anforderungen, wenn er leer ist R4: Der Puffer blockiert Put()-Anforderungen, wenn er voll ist Aspekt Blockieren R5: Die Elemente des Puffers werden nicht auf den Heap gelegt R6: Es können mehrere Clients gleichzeitig auf den Puffer zugreifen R7: Der Puffer kann im Flash-Speicher persistent gehalten werden R8: Zugriffe auf den Flash-Speicher werden gesammelt und finden in Blöcken statt
Schwachstellen der AOP Probleme ähnlich wie beim Übergang zu C++ im Embedded-Bereich: Wenig Grundlagenwissen/Best Practices Im Embedded-Bereich extrem unübliche Vorgehensweise Kann zu extrem schlechter Lesbarkeit führen Kritisches Hinterfragen der Haupt- und Nebenzerlegungen nötig Was ist Hauptprogramm? Was sind Aspekte? Wie kann im Embedded-Bereich mit Aspekten umgegangen werden?
UML Diagramme & Aspekte 1 Sinnvolle Vorgehensweisen bei Darstellung von Aspekten in UML-Diagrammen: Jeweils nur ein Thema/Aspekt pro Diagramm Die Diagramme zusammen ergeben dann die Software Die einzelnen Themen/Aspekte bleiben verständlich Farbliche Gliederung von Aspekten kann hilfreich sein Die Umwandlung in Code erfolgt meist früh (zum Zeitpunkt des Einfügens von Diagrammen).
UML Diagramme & Aspekte 2 Klassendiagramme : Aspekte vermengt: unübersichtlich 25 Command1Factory Command::CommandMemory::Command1Factory 1 Command1 CreateCommand1():Command1 DestroyCommand1(pCommand:pCo... 25 «create» «create» «Interface» ICommand Command1 1 «Interfac e» ICom mand Command1
UML Diagramme & Aspekte 3 Klassendiagramme : Aspekte lassen sich sehr gut einzeln darstellen Es wird Code durch die Klassendiagramme erzeugt Es lässt sich kein Verhalten modellieren/codieren Sequenzdiagramme: Aspekte lassen sich oft einzeln darstellen Abhängig vom gewählten Szenario Low-Level-Aspekte oft schwierig (Trennung Aspekt/ Hauptprogramm nicht immer aus Programmfluss erkennbar) Die Aspektdarstellung bleibt oft unvollständig Es lässt sich Verhalten modellieren
UML Diagramme & Aspekte 4 Statecharts: Es lässt sich Verhalten codieren Ereignisse bieten starke Abstraktion/Kapselung Aspekte können detailliert modelliert werden Kann geschwätzige Klassen erzeugen Jeder Wechsel in jeden Zustand wird vorsichtshalber mitgeteilt Es wird versucht Aspekte vorherzusehen Wie lassen sich Statecharts effizient zur Codierung von Aspekten einsetzen?
UML Diagramme & Aspekte 5 Statecharts: Aspekte in parallelen Zuständen state_1 Hauptprogramm Aspect1 Aspect2 Broadcast-Events erlauben es, den Empfänger-Aspekt nicht zu kennen Für einfache (Teil-)Modelle Wird schnell unübersichtlich Kann sehr einfach erweiterbar sein, da Objekt mit sich selbst kommuniziert Ist schnell ineffizient (NULL-Events & Timer )
UML Diagramme & Aspekte 6 Statecharts: Aspekte in eigenen Klassen: Mehrere Klassen kommunizieren Objekte müssen sich kennen oder über Aspect1 Vermittler kommunizieren Klassen leichter austauschbar Für große Systeme besser wartbar Hauptprogramm «communicate» «communicate» «communicate» Vermittler «communicate» «communicate» «communicate» «communicate» «communicate» Aspect2
UML Diagramme & Aspekte 7 Packages: Natürliche Einheit für einen Aspekt: Requirements Klassen Diagramme Unloaded Packages Ermöglichen späte Bindung in Verbindung mit SCM- Tools (?)
Design Pattern und Aspekte Was sind Design Pattern? Gut dokumentierte Kombination von Aufgabenstellung, Lösungsansatz und sich aus Lösung ergebenden Konsequenzen Design Pattern können bei der Implementierung von Aspekten sehr unterstützen, wenn sie schon im Code vorhanden sind. Oft stellen neue Aspekte die Notwendigkeit für ein Refactoring (auch hin zu Patterns) heraus. Hier eine kleine Auswahl von Beispielen: Command, Observer, Chain of Responsibility, Visitor.
Design Pattern und Aspekte 2 Das Pattern Command Klient Aufrufer 1 1 «Interface» IBefehl FuehreAus():void KonkreterBefehl «create» FuehreAus():void Empfaenger 1 1 FuehreAus arbeitet auf Empfänger und kann eine komplette Strategie zur Realisierung eines Aspekts enthalten.
Design Pattern und Aspekte 3 Das Pattern Command Anwendungsbeispiele: Schnittstellen GUI / Applikationslogik völlig entkoppelt Fehlerhandling (Aufrufer parametriert Fehlerreaktion in Befehl) Oft kann komplette Logik eines Aspekts in Befehl gekapselt werden (mehrere Empfänger, ) Durch Übergabe mehrerer Befehle für verschiedene Situationen lässt sich auch hochkomplexes Verhalten parametrieren
Properties/Stereotypen & Aspekte 1 Properties können Codegenerierung verändern und damit Aspekte berücksichtigen Beispiel: Memory Management
Rhapsody in C ein System zur aspektorientierten Embedded- Entwicklung? Properties/Stereotypen & Aspekte 2 Woran erkennt man, dass Properties überschrieben sind? Stereotypen können als Behälter für Properties dienen! Beispiel: Memory Management Bilde Stereotypen PoolAlloc, anwendbar auf Klassen Überschreibe dort die Property C_CG::Class::AllocateMemory zu ($cname *) AllocPooled(sizeof($cname)); Überschreibe dort die Property C_CG::Class::Memory zu FreePooled($meName, sizeof($cname)); Jede Klasse mit diesem Stereotypen erzeugt/zerstört sich nicht über malloc/free sondern die Funktionen AllocPooled und FreePooled Aspektorientiert!
Properties/Stereotypen & Aspekte 3 Properties/Stereotypen: Sehr universell einsetzbar Über Properties: relativ schlecht lesbar Über Stereotypen: deutlich besser lesbar Relativ schwer zu warten Häufig Berührungsängste bei den normalen Rhapsody- Programmierern Jetzt auch mehrere Stereotypen möglich! Einbinden eines externen Postprozessors ermöglicht nachträgliche Bearbeitung des Codes und damit spätes Erzeugen des Codes (z.b. Perl)
Codegenerator & Aspekte Über die Modifikationen des Codegenerators lassen sich noch weitere aspektorientierte Techniken realisieren! Hier sind auch Dinge wie Prüfung aller Pointer auf NULL möglich. Es könnten sogar generische Beschreibungen erfolgen, die spezifizieren, wann Aspekte angewendet werden sollen. Hierzu ist eine Spezialisierung des Codegenerators nötig. Diese Modifikationen entwickeln Rhapsody immer mehr zu einer Domain-spezifischen Sprache, da bevorzugt Domainspezifische Aspekte implementiert werden. Es wird immer schwerer Personal zu finden, das mit diesen Techniken umgehen kann.
Zusammenfassung Rhapsody eignet sich prinzipiell, um Aspekte sinnvoll bei der Software-Entwicklung zu berücksichtigen. Je universeller und einfacher die Berücksichtigung von Aspekten sein soll, desto: mehr Customizing-Aufwand fällt an größere Kluften entstehen zwischen Aspektentwicklern und -anwendern schwieriger wird die Suche nach diesbezüglich erfahrenen Arbeitskräften Ist hier eine standardisierte Vorgehensweise sinnvoll?