Autor: Johannes Scheier, Z\u00fcrcher Hochschule f\u00fcr angewandte Wissenschaften<\/p>\n
Modellgetriebene Software-Entwicklung ist ein Ansatz mit enormem, nur teilweise ausgesch\u00f6pftem Potential. Je verst\u00e4ndlicher und lesbarer die Modelle, desto gr\u00f6\u00dfer ist ihr Nutzen. UML (Unified Modelling Language) sieht die M\u00f6glichkeit vor, die Sprache durch eigene Abstraktionen zu erweitern. Nachfolgend wird CIRO (Communicating Interacting Reactive Objects), eine auf diesem Me\u00adchanismus basierende Erweiterung, vorgestellt.<\/strong><\/p>\n Modellgetriebene Software-Entwicklung ist eine Vorgehensweise zur Modellierung und anschliessenden Code-Generierung von Software-Systemen. Dabei wird ein formales, vollst\u00e4ndiges und plattformunabh\u00e4ngiges Modell erstellt und daraus der plattformspezifische Code generiert. Das Modell beschreibt die Struktur und das Verhalten des Systems.<\/p>\n CRIO ist eine Sammlung von Abstraktionen und Konzepten, die bei der Modellierung von Embedded Systemen hilfreich sind. CIRO definiert eine generische Software-Architektur, synchrone und asynchrone Kommunikationsmechanismen zwischen Objekten sowie eine Systemstruktur als Komposition von wiederverwendbaren Komponenten. Eine fundamentale Rolle kommt dabei den qualifizierten Konnektoren zu, einem Konzept zur Definition der Interaktion von Komponenten innerhalb einer Komposition.<\/p>\n CIRO basiert auf CIP (Communicating Interacting Processes), einer modellbasierten Entwicklungsmethodik f\u00fcr Embedded Systeme. CIP wurde 1999 an der ETH Z\u00fcrich von Prof. Dr. Hugo Fierz entwickelt [1].<\/p>\n Als Ausgangspunkt f\u00fcr die Modellierung in CIRO dient die nachfolgend beschriebene generische Software-Architektur f\u00fcr Embedded Systeme (Abb. 1, siehe\u00a0PDF<\/a>). Diese Architektur l\u00e4sst sich auf Systeme anwenden, welche technische Prozesse aufgrund von physikalischen Ereignissen steuern. Das Embedded System reagiert auf Ereignisse in den technischen Prozessen mit Aktionen, welche die technischen Prozesse beeinflussen. Sei ein technischer Prozess beispielsweise eine Heizung, dann reagiert das Embedded System auf das Ereignis\u00a0tempHigh<\/em>\u00a0mit der Aktion\u00a0heatingOff<\/em>.<\/p>\n Wir stellen uns vor, dass die technischen Prozesse direkt mit der Reactive-Machine kommunizieren und mit dieser Event- und Action-Messages austauschen \u2013 diese vorgestellte Interaktion bezeichnen wir als virtuelle Interaktion (siehe (a) in Abb. 1,\u00a0PDF<\/a>). In Tat und Wahrheit wird diese Kommunikation in der Connection-Schicht des Embedded Systems implementiert, wobei der technische Prozess \u00fcber Sensoren mit dem Embedded System verbunden ist. Aus den Signalen der Sensoren werden die Ereignisse detektiert und als Event-Messages \u00fcber eine Message-Queue an die Reactive-Machine weitergereicht. Die Reactive-Machine sowie die Connection sind passive Komponenten. Die Execution, quasi die main()-Funktion, ist f\u00fcr den Aufruf dieser Komponenten verantwortlich.<\/p>\n Eine Unit ist eine ausf\u00fchrbare Einheit, welche parallel zu anderen Units ausgef\u00fchrt werden kann. Eine Unit besteht aus Reactive-Machine, Connection und Execution. Mehrere Units k\u00f6nnen auf verschiedene Threads oder auch auf mehrere Prozessoren verteilt werden.<\/p>\n Die Reactive-Machine reagiert auf Events in den technischen Prozessen und l\u00f6st Actions an denselben aus. Die Reactive-Machine und die Connection sind passiv und werden durch die Execution aktiviert.<\/p>\n Im Folgenden werden die Komponenten dieser Software-Architektur beschrieben. Als Beispiel dient ein Modell f\u00fcr die Steuerung einer Schiebet\u00fcre, welche im Rahmen eines Praktikums von den Studenten der ZHAW entwickelt wird (Abb. 2, siehe\u00a0PDF<\/a>).<\/p>\n Reactive-Machine Die Reactive-Machine selbst ist eine Komposition von\u00a0Reactive-Clusters<\/strong>, welche ihrerseits aus Reactive-Objects bestehen. \u00dcber Reactive-Cluster-Grenzen kann nur asynchron \u00fcber Event- und Action-Messages kommuniziert werden. Innerhalb der Cluster-Grenzen kann synchron \u00fcber Pulse und State-Queries kommuniziert werden.<\/p>\n (rote Elemente in Abb. 4, siehe\u00a0PDF<\/a>)<\/p>\n Das Verhalten eines Reactive-Object ist in einer State-Machine definiert (Abb. 5, siehe\u00a0PDF<\/a>). Jede State-Transistion hat einen Ausl\u00f6ser (Trigger) und kann einen Output (Action) erzeugen. Nebst dem Trigger k\u00f6nnen Bedingungen (Guards) zu State-Transitions definiert werden. Als Trigger kommen In-Pulse und Event-Messages in Frage, als Actions Out-Pulse und Action-Messages und als Guard sogenannte Gates. Dabei gilt folgende Syntax: trigger[guard]\/action (Abb. 5, siehe\u00a0PDF<\/a>)<\/p>\n (graue Elemente in Abb. 4, siehe\u00a0PDF<\/a>)<\/p>\n Innerhalb eines Reactive-Clusters k\u00f6nnen Reactive-Objects synchron miteinander interagieren. Die Mechanismen zur synchronen Interaktion sind Pulse-Cast und State-Inspection.<\/p>\n Ein\u00a0Pulse-Cast<\/strong>\u00a0ist eine Interaktion zwischen Reactive-Objects, wobei ein ausgesendeter Out-Pulse in In-Pulses von Empf\u00e4ngerobjekten \u00fcbersetzt werden. So wird beispielsweise in ((a) Abb. 4, siehe\u00a0PDF<\/a>) der Out-Pulse\u00a0oPress<\/em>\u00a0von\u00a0button<\/em>\u00a0in den In-Pulse\u00a0iOpen<\/em>\u00a0von\u00a0doorControl<\/em>\u00a0\u00fcbersetzt.<\/p>\n State-Inspection\u00a0<\/strong>ist eine Interaktion zwischen Reactive-Objects, bei der das inspizierende Objekt eine Gate-Operation aufruft, welche in eine logische Abfrage von Zust\u00e4nden der inspizierten Objekte \u00fcbersetzt wird. So ist beispielsweise der logische Ausdruck f\u00fcr\u00a0canClose:<\/em>\u00a0!lightBarrier.Interrupted && openButton.Released\u00a0<\/em>((b) in Abb. 4, siehe\u00a0PDF<\/a>), d.h. die T\u00fcre kann nur geschlossen werden, wenn die Lichtschranke nicht unterbrochen ist und der \u00d6ffnen-Knopf losgelassen ist.<\/p>\n Die Interaktionsdefinitionen sind den Verbindungen zwischen Objekten zugeordnet, den sogenannten\u00a0qualifizierten Konnektoren<\/strong>. Diese sind wie die Objekte selbst Bestandteile der Komposition. Die interagierenden Objekte bzw. deren Klassen sind unabh\u00e4ngig voneinander. Dies f\u00fchrt zu einer gro\u00dfen Flexibilit\u00e4t und Wiederverwendbarkeit.<\/p>\n Die\u00a0Connection<\/strong>\u00a0liest die Eingangssignale, detektiert Event-Messages und leitet diese an die Reaktive-Machine weiter. Das Modell der Connection ist wiederum eine hie\u00adrarchische Struktur, deren Komponenten Instanzen wiederverwendbarer Klassen sind.<\/p>\n Execution<\/strong>\u00a0ist f\u00fcr das Scheduling innerhalb der Unit verantwortlich. In der Regel ist das die main()- oder run()-Operation der Unit-Task, welche zyklisch die Connection und die Reactive-Machine aufruft (Abb. 7, siehe\u00a0PDF<\/a>).<\/p>\n Das Modell der Reactive-Machine ist ausf\u00fchrbar bzw. simulierbar d.h. es k\u00f6nnen Event-Messages eingespeist und die entsprechenden Reaktionen verfolgt werden.<\/p>\n Sobald die funktionalen Anforderungen bekannt sind und das Interface zur Reactive-Machine definiert ist, k\u00f6nnen\u00a0Test-Cases<\/strong>\u00a0definiert werden, z.B. als Sequenz-Diagramme (Abb. 9, siehe\u00a0PDF<\/a>). Aus Sicht der Test-Cases ist die Reactive-Machine eine Blackbox.<\/p>\n Der Code f\u00fcr auf dem Target ausf\u00fchrbaren die Units kann vollst\u00e4ndig aus dem Modell generiert werden.<\/p>\n Die qualifizierten Konnektoren sind UML-Links, welche um zus\u00e4tzliche Aussagen zur Verbindung erweitert werden, beispielsweise Pulse-Cast oder State-Inspection (siehe oben). Dieses Konzept l\u00e4sst sich ganz allgemein auf jede Verbindung von Objekten innerhalb einer Komposition anwenden und erh\u00f6ht die Flexibilit\u00e4t und Wiederverwendbarkeit enorm.<\/p>\n CIRO erm\u00f6glicht mit wenigen kleinen UML-Erweiterungen eine effektivere Anwendung von modellgetriebener Software-Entwicklung f\u00fcr Embedded Systeme.<\/p>\n Diese Erweiterungen basieren zum gro\u00dfen Teil auf dem allgemeineren Konzept der qualifizierten Konnektoren, welches auch in anderen Gebieten der Modellierung an\u00adgewendet werden kann.<\/p>\n CIRO ist tool-unabh\u00e4ngig. Es existieren Realisierungen f\u00fcr ActifSource und IBM Rhapsody. Weitere sollten sich mit vertretbarem Aufwand implementieren lassen.<\/p>\n [1] Fierz, Hugo. (1999). The CIP Method: Component- and Model-Based Construction of Embedded Systems. ACM Sigsoft Software Engineering Notes. 24. 375-392. 10.1007\/3-540-48166-4_23.<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Modellierung \/Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Modellierung \/Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nGenerische Software-Architektur<\/h2>\n
\nDie Interaktion zwischen Reactive-Machine und technischen Prozessen erfolgt je\u00addoch indirekt \u00fcber die Connection, welche Ereignisse detektiert und als Event-Messages an die Reactive-Machine weiterleitet. Andererseits nimmt die Connection Action-Messages von der Reactive-Machine entgegen und leitet diese als elektrische Signale an die Aktuatoren weiter.<\/p>\nReactive-Machine<\/h2>\n
\n<\/strong>Das Interface der Reactive-Machine l\u00e4sst sich aus der virtuellen Interaktion ableiten. Es besteht aus Ports. F\u00fcr jedes Port wird definiert, welche Messages empfangen oder gesendet werden k\u00f6nnen (Abb. 3, siehe\u00a0PDF<\/a>).<\/p>\nReactive-Object<\/h2>\n
Synchrone Interaktion von Reactive-Objects<\/h2>\n
Simulation und Testing<\/h2>\n
Code-Generierung<\/h2>\n
Qualifizierte Konnektoren<\/h2>\n
Zusammenfassung<\/h2>\n
Literaturverzeichnis<\/h2>\n
\nModellierung – MicroConsult Trainings & Coachings<\/h2>\n
\nModellierung – Fachwissen<\/h2>\n