Architekturmodell: der Weg zur Klassen-Hierarchie

Transkript

1 Betriebssystemtechnik Operating System Engineering (OSE) Domänenentwurf Domänenmodell Domänenentwurf Feedback/Anpassungen Reverse Architecting teuer Referenzarchitektur Architekturmodell: der Weg zur Klassen-Hierarchie Analyse Identifikation der Architekturtreiber, Mechanismen und Sichten Modellierung? Architekturdokumentation mit Variationspunkten Evaluierung Erkennen von Risiken in den Entwurfsentscheidungen In Anlehnung an das Modell zur Architekturentwicklung aus []. 007 Olaf Spinczyk Architektur-Modellierung bisher haben wir diverse Hierarchien Modul-Hierarchie Funktionale Hierarchie [] Benutzt-Hierarchie [] jetzt kommt noch eine hinzu: die Belang-Hierarchie [] gesucht ist eine Modulstruktur durch Programmiersprache bestimmt: AspectC++ - Klassen, Methoden, Aspekte, (Templates) Funktionale Hierarchie von FAMOS a time sharing system special devices user interface swapping a process control system address space creat. synchronization process managem. address spaces job control language file systems disk i/o process creation a batch system Was genau bedeutet das? hardware [] 007 Olaf Spinczyk 007 Olaf Spinczyk

2 Das Modell der funktionalen Hierarchie Funktionale Hierarchie Elemente Funktionen elementare Systembausteine der Software (Entwurfsebene) logische Funktionen file system file system 007 Olaf Spinczyk Olaf Spinczyk 6 Funktionale Hierarchie Elemente Funktionale Abhängigkeiten logische Abhängigkeiten zwischen Systembausteinen ( verwendet ) müssen einen azyklischen Graphen ergeben Funktionale Hierarchie Elemente Ebenen Gruppierung zusammenhängender Funktionen Ebene 0 ist die Hardware Ebenen n fügen virtuelle Hardware als minimale Erweiterungen hinzu Functionen der Ebene n kennen alle Funktions der Ebenen 0n file system file system 007 Olaf Spinczyk Olaf Spinczyk 8

3 Funktionale Hierarchie Vorteile verständlich gut für bottom-up Entwicklung geeignet feingranulare Konfigurierbarkeit durch minimale Erweiterungen erfordert keine speziellen Implementierungsmechanismen It is the system design which is hierarchical, not its implementation Habermann, 976 [] file system Das PURE Projekt (995 00) Ziel: Herausforderungen Eine hochgradig konfigurierbare BS Produktlinie für eingebettete Systeme Umgang mit großer Variabilität im Problemraum Umsetzung der Variabilität im Lösungsraum Entwicklungsmethoden Merkmalmodelle Funktionale Hierarchien - Beschreibung der Variabilität - Variabler Entwurf 007 Olaf Spinczyk Olaf Spinczyk 0 Problem : keine Verschachtelung Problem : keine Verschachtelung hochgradig konfigurierbare Systeme können nicht durch eine einzige FH beschrieben werden Beispiel: PURE Prozessverwaltung - Ebenen - konfigurierbar in Bezug auf - Scheduling-Strategie - Prozess-Kontext - Systemschnittstelle - hochgradig konfigurierbare Systeme können nicht durch eine einzige FH beschrieben werden Lösungsansatz: Beispiel: PURE Prozessverwaltung - Rekursive Ebenen Modellierung komplexer Funktionen als Familie in der Familie. - konfigurierbar in Bezug auf - Scheduling-Strategie - Prozess-Kontext erlaubt schrittweise Verfeinerung - Systemschnittstelle Olaf Spinczyk 007 Olaf Spinczyk

4 Problem : Querschneidende Belange eine Implementierung mit Aspekten kann nur schwer abgeleitet werden Problem : Querschneidende Belange eine Implementierung mit Aspekten kann nur schwer abgeleitet werden Beispiel: PURE Unterbrechungssynchronisation - 66 Join-Points - 5 betroffene Klassen Beispiel: PURE Unterbrechungssynchronisation - 66 Join-Points - 5 betroffene Klassen Lösungsansatz: Explizite Modellierung querschneidender Belange 007 Olaf Spinczyk 007 Olaf Spinczyk Das Modell der Belang-Hierarchien Belang-Hierarchien Elemente Erweiterung der funktionalen Hierarchien beschreibt funktionale Abhängigkeiten (zyklenfrei) erfasst quer schneidende Belange in den Funktionen erlaubt Verfeinerungen von Funktionen durch Unterbelang- Hierarchien Herkömmliche Belange wie Funktionen in funktionalen Hierarchien 007 Olaf Spinczyk Olaf Spinczyk 6

5 Belang-Hierarchien Elemente Belang-Hierarchien Elemente Querschneidende Belange modellieren Belange, die in verschiedenen herkömmlichen Belangen zu berücksichtigen sind. Belanggruppen entsprechen AOP Pointcuts ein einzelner Belang ist implizit eine Gruppe (seiner Unterbelange) 007 Olaf Spinczyk Olaf Spinczyk 8 Belang-Hierarchien Elemente Belang-Hierarchien Elemente Funktionale Abhängigkeiten wie in funktionalen Hierarchien querschneidende Belange können auch funktionale Abhängigkeiten haben Beeinflussung/Aktivierung ein querschneidender Belang beeinflusst ein Belanggruppe dabei wird der querschneidende Belang aktiviert 007 Olaf Spinczyk Olaf Spinczyk 0

6 Belang-Hierarchien Elemente Notwendige Beeinflussung/Aktivierung wenn die jeweilige Aufgabe ohne die Beziehung nicht erfüllt werden kann Beeinflussung und Aktivierung notwendige Beeinflussung notwendige Aktivierung 007 Olaf Spinczyk 007 Olaf Spinczyk Ableitung eines Abhängigkeitsmodells Ableitung eines Abhängigkeitsmodells 007 Olaf Spinczyk 007 Olaf Spinczyk

7 Beispiel: Lehrstuhl Wetterstation Lässt die Belang-Hierarchie aus dem Merkmalmodell systematisch ableiten? Merkmaldiagramm: Lehrstuhl AVR-Wetterstationssoftware WeatherMon Beispiel: Lehrstuhl Wetterstation Lässt die Belang-Hierarchie aus dem Merkmalmodell systematisch ableiten? Merkmaldiagramm: Lehrstuhl AVR-Wetterstationssoftware WeatherMon Alarm Actors Sensors Display PC Connection Temperature Air Pressure Wind Speed RSLine USBLine Protocol Actors Sensors Nein, nicht vollständig im Merkmalmodell fehlen Belange, die zwar für die Implementierung notwendig sind, aber zum Alarm Display Zwecke PC der Connection Konfigurierung Temperature uninteressant Air sind: Pressure Wind Speed Anforderungen sind dokumentierte Belange allerdings sollten die hier dokumentierten Belange RSLine USBLine Protocol auch in der Belang-Hierarchie wieder auftauchen. SNGProto XMLProto SNGProto XMLProto 007 Olaf Spinczyk Olaf Spinczyk 6 Beispiel: Lehrstuhl Wetterstation Belang-Hierarchie: Lehrstuhl AVR-Wetterstationssoftware Beispiel: Lehrstuhl Wetterstation Belang-Hierarchie: Lehrstuhl AVR-Wetterstationssoftware Steuerlogik Steuerlogik alle messen Main-Loop alle arbeiten Verarbeitung (Aktoren) Verarbeitung alle abfragen Anzeige PC via XML PC via SNG Leitung Messung (Sensoren) Messung Druckmessung Windmessung Temperaturmessung Wetterdaten (-haltung und -repräsentation) Wetterdaten Druckspeicherung Windspeicherung Temperaturspeicherung 007 Olaf Spinczyk Olaf Spinczyk 8

8 OO vs. familienbasierter Entwurf Vererbung kann als Vehikel für die schrittweise Erweiterung genutzt werden Pro program families funktionale Hierarchien lassen sich (relativ) leicht in eine Modulstruktur transformieren Contra minimal subset incremental system design minimal extension inheritance base class derived class object orientation Entwurf wird leicht als schlechter OO-Entwurf missverstanden [] Funktionen werden Klassen () die funktionale Hierarchie wird einfach auf den Kopf gestellt : Eigenschaften: Pressure unsigned _p string to_string() PressureSensor void messure() Konfigurierung durch Anwender + Binder eventuell Mehrfachvererbung Trennung des Zustands bei Funktionen einer Ebene eignet sich für grobe Funktionen Klassen ohne Attribute machen z.b. selten Sinn 007 Olaf Spinczyk Olaf Spinczyk 0 Funktionen werden Klassen () Funktionen einer Ebene können auch zu einer Klasse zusammengefasst werden: Eigenschaften: Weather unsigned _p unsigned _w unsigned _t string p_str() string w_str() string t_str() Konfigurierung eventuell durch Anwender + Binder gemeinsamer Zustand möglich für kleine Funktionen die angenehmere Schnittstelle VP VP VP VP VP VP Querschn. Belange werden Aspekte alle abfragen <<aspect>> SensorManagement SensorRegistry reg; (A) construction RegIterator iter() <<affects>> PressureSensor WindSensor Druckspeicherung Druckmessung Druckspeicherung Windspeicherung Temperaturspeicherung Druckspeicherung Windspeicherung Temperaturspeicherung TemperatureSensor Eigenschaften: Entkopplung der Funktionen erleichtert Konfigururierung nicht immer möglich/sinnvoll 007 Olaf Spinczyk 007 Olaf Spinczyk

9 Konfigurierbare Funktionen machen eine gemeinsame Schnittstelle notwendig: PC via XML wahlweise statisch gebunden, z.b. Klassenalias oder dynamisch gebunden, z.b. mit abstrakter Klasse Port PC via SNG USB Port RS Port Leitung 007 Olaf Spinczyk Zusammenfassung Grundregeln bei der Ableitung einer AO-Klassenhierarchie aus einer Belang-Hierarchie: Erweiterungen (Ebenen) werden durch Vererbung ausgedrückt Querschneidende Belange können i.d.r. als Aspekte realisiert werden Konfigurierbare Funktionen erfordern eine Schnittstellendefinition - Bindung kann statisch oder dynamisch erfolgen - das Hinzufügen abstrakter Schnittstellenklassen erfolgt immer anwendungsgetrieben, d.h. die Entwicklung beginnt nicht mit einer abstrakten Klasse wie es in OO-Entwürfen oft zu finden ist der Prozess vermeidet zwecks Konfigurierbarkeit zyklische Abhängigkeiten in der Modulstruktur 007 Olaf Spinczyk Ausblick Literatur Untersuchung verschiedener Techniken zur Umsetzung von Variabilität in der Implementierung der Komponenten Stand der Kunst: Beispiel ECOS Werkzeugbasierte Lösungen Programmiersprachenbasierte Lösungen [] O. Spinczyk. Aspektorientierung und Programmfamilien im Betriebssystembau. Dissertation, Otto-von-Guericke- Universität Magdeburg, 00. [] W. Schröder-Preikschat. The Logical Design of Parallel Operating Systems. Prentice Hall, 99. ISBN [] A. N. Habermann, L. Flon, and L. Cooprider. Modularization and Hierarchy in a Family of Operating Systems. Communications of the ACM, 9(5):66-7, 976. [] D. L. Parnas. Some Hypotheses about the 'uses' Hierarchy for Operating Systems, Technical Report, Technische Hochschule Darmstadt, Darmstadt, West Germany, Olaf Spinczyk Olaf Spinczyk 6