Model-Based Construction of Embedded & Real-Time Software - A Methodology for Small Devices

Zusammenfassung:

Die vorliegende Arbeit ist in drei Teile gegliedert, die insgesamt elf Kapitel umfassen.   Teil 1: Foundations Nach einer kurzen Betrachtung des Kontextes dieser Arbeit, werden im zweiten Kapitel grundlegende Begriffe eingeführt und definiert. So wird ein klarer begrifflicher Rahmen geschaffen, der im weiteren Verlauf der Arbeit durchgängig genutzt wird. Kapitel 3 enthält eine sehr umfangreiche historische Übersicht über methodische Ansätze der Softwareentwicklung und beschreibt anschließend den Stand der Technik und der Praxis im Bereich der Softwarekonstruktion für eingebettete Systeme. Der erste Teil schließt mit einer detaillierten Vorstellung der betrachteten Anwendungsdomäne (Entwicklung von Messgeräten) ab. Darauf basierend werden die zentralen Problemstellungen und Ziele dieser Arbeit beschrieben.   Teil 2: The MeDUSA-ViPER Methodology Dieser Teil fasst die zentralen Ergebnisse der Arbeit zusammen. Bevor die Methode MeDUSA vorgestellt wird, wird die Ausgangslage für die erstellte Gesamtlösung skizziert. Dazu zählen die Methoden COMET und ROOM sowie auf der Werkzeugseite die IBM Software Development Plattform und das Werkzeug Jaczone Waypointer. Deren Kenntnis ist wesentlich, weil einige Ideen und Konzepte, die auch für die betrachtete Anwendungsdomäne geeignet sind, in die Entwicklung von MeDUSA und ViPER eingeflossen sind.   Die Methode MeDUSA: In Kapitel 6 wird die entwickelte Methode konform zum Standard SPEM (Software Process Engineering Meta-Model) vorgestellt. Auf oberster Ebene definiert die Methode sechs Arbeitsbereiche: Requirements Modeling, Analysis Modeling, Architectural Design Modeling, Detailed Design Modeling, Implementation und Real-Time Analysis. Die jeweils darin zusammengefassten Tätigkeiten erstellen und bearbeiten die drei respektive vier zentralen Arbeitsergebnisse: das Anforderungs-, Analyse- und Entwurfsmodell sowie die Implementierung. Ein wesentliches Merkmal der Methode ist, dass im Gegensatz zu anderen (z.B. COMET, ROOM) auf der Exemplarebene modelliert wird. Der Grund dafür liegt darin, dass die betrachteten Softwaresysteme ein laufzeitstabiles Objektgeflecht haben, dass einmal initialisiert nicht mehr verändert wird.   Ein zentraler Bestandteil des Anforderungsmodells bildet das Modell der Use Cases. Eine in diesem Bereich tragfähige Akteur-Klassifikation sorgt dafür, dass die für die Anwendungsdomäne typischen Anforderungen an Zeitverhalten und Nebenläufigkeit explizit bereits auf dieser Ebene modelliert werden können. So lassen sich nicht nur periodische und aperiodischer Trigger, sondern auch Akteure in Use Case Modellen definieren, die ein spezielles Synchronisationsverhalten modellieren. Zusätzlich können mit Hilfe von Interface-Akteuren die Schnittstellen zur umgebenden Hardware und Software modelliert werden. Da einige Akteure als Teil der zu erstellenden Software angesehen werden (z.B. Timer), müssen diese systemintern definiert werden; es entstehen sogenannte interne Akteure. Dieses Konzept erweitert das Use Case Meta-Modell, wie es die UML definiert.   Da MeDUSA im Kern exemplarbasiert (in der Implementierung dann auch klassenbasiert) ist, ist das Ziel der Analyse, die zentralen Objekte zu finden, die die Leistung des Systems erbringen. Auch dieser Arbeitsbereich wird durch eine Klassifikation unterstützt, die die Typen der Analyseobjekte vorgibt. Sie unterscheidet aktive und passive Objekte und erweitert eine Klassifikation, die von COMET vorgeschlagen wurde. Durch die verschiedenen Tätigkeiten, die im Arbeitsbereich Analysis Modeling zusammengefasst werden, kann sowohl die statische Struktur der Analyseobjekte als auch ihr internes und systemweites Verhalten spezifiziert werden. Dementsprechend besteht das Analysemodell aus einer Reihe von UML Struktur- und Verhaltensdiagrammen.   Im anschließenden Architekturentwurf (Architectural Design Modeling) werden die identifizierten Analyseobjekte modularisiert, es entstehen Subsysteme. Deren Strukturierung, ihre Schnittstellen und ihr Zusammenspiel werden durch entsprechende UML-Diagramme beschrieben. Basierend auf dem Ergebnis des Architekturentwurfs werden die definierten Subsysteme im Detailentwurf verfeinert (dies kann parallel und verteilt geschehen). Am Ende der gesamten Entwurfstätigkeiten sind alle Klassen für alle Subsysteme auf der Ebene von zentralen Attributen und Methoden definiert. Da das Entwurfsmodell die Vorgabe für die abschließende Implementierung ist, nutzt MeDUSA als modellbasierte Methode dessen Informationen, um eine zur Architektur konsistente Codebasis zu generieren. Dies geschieht in einem Transformationsprozess, der als Eingabe das Entwurfsmodell und als Ausgabe Coderümpfe in ANSI-C hat. Diese Rümpfe sind im letzten Schritt zu implementieren und miteinander zu integrieren.   Neben diesen konstruktiven Arbeitsbereichen unterstützt MeDUSA die Analyse von Zeitanforderungen. Da bereits im Use Case Modell Zeit‐ und Nebenläufigkeitsanforderungen explizit spezifiziert werden können, können diese Informationen schon frühzeitig genutzt werden, um erste sehr grobe Abschätzungen und Bewertungen durchzuführen. Diese werden mit zunehmender Präzision in der Analyse und im Architekturentwurf verfeinert. Damit wird gewährleistet, dass dieser sehr zentrale Aspekt entwicklungsbegleitend berücksichtigt wird.   Nachdem diese Arbeitsbereiche detailliert vorgestellt und mit Hilfe eines durchgängigen Beispiels erläutert wurden, konzentriert sich der zweite Teil der Methodenbeschreibung (gemäß SPEM) darauf, wie die Arbeitsbereiche und ihre Tätigkeiten zeitlich angeordnet in einem Entwicklungsprojekt durchgeführt werden. Dazu wird für jeden Arbeitsbereich ein im Kern iterativer Workflow definiert, diese werden anschließend zum gesamten ebenfalls iterativen MeDUSA‐Workflow verbunden. Eine Bewertung und Abgrenzung der vorgestellten Methode schließt das Kapitel 6 ab.   Sprachen: Kapitel 7 befasst sich mit den Sprachen und Spracherweiterungen, die verwendet werden bzw. notwendig sind, um die in MeDUSA definierten Modelle und Teilmodelle zu formulieren. Die Basis für den überwiegenden Teil der Modelle bildet die UML. Da die definierten Modelle jedoch speziell auf die Software im betrachteten Anwendungsbereich zugeschnitten sind, wird auf der einen Seite nur ein Ausschnitt der UML verwendet. Auf der anderen Seite werden Modellierungsmöglichkeiten benötigt, die der UMLStandard nicht zur Verfügung stellt. Im ersten Teil dieses Kapitels werden die MeDUSA UML-Modelle im Detail vorgestellt, indem auf Exemplarebene die in den Modellen ausgeprägten Metaklassen und Meta-Assoziationen erläutert werden. Dies zeigt sehr detailliert, wie welche UML-Metaelemente zu den einzelnen MeDUSA UML-Modellen beitragen. So kann sichergestellt werden, dass die einzelnen Modelle einer modellbasierten Methode auch bruchfrei und konsistent zueinander passen. Anschließend werden die UML-Spracherweiterungen der MeDUSA UML-Modelle durch sogenannte UML-Profile definiert.   Da MeDUSA als Implementierungssprache ANSI‐C unterstützt, wird abschließend beschrieben, wie auf Basis des entwickelten Entwurfsmodells eine ANSI-C-konforme Implementierung erstellt wird. Wie bereits erwähnt, kann der „strukturelle“ Code aus dem Entwurfsmodell generiert werden. Dies geschieht durch sogenannte Modell-zu-Modell- und Modell-zu-Text-Transformationen. Zuerst wird die generelle Transformationsstrategie erläutert. Diese sieht vor, dass die Strukturelemente des Entwurfsmodells (UML Classifier) in entsprechenden ANSI-C Code transformiert werden. Anschließend werden die definierten Transformationen entlang dieser Strukturelemente im Detail definiert. Dabei ist die vorab erfolgte präzise Definition der Modellbestandteile des Entwurfsmodells, das die Eingabe für die Transformationen ist, in Form von Metaklassen und Meta-Assoziationen von immensem Vorteil. So können die Transformationen ebenfalls detailliert und präzise spezifiziert werden.   Die Werkzeugunterstützung ViPER: Kapitel 8 beschreibt die entwickelte Werkzeugplattform. ViPER ist eine Entwicklungsumgebung für graphische Editoren und Modelltransformationen. Sie basiert auf Eclipse und integriert und nutzt eine Vielzahl von Eclipse‐Technologien. Zuerst wird ein Überblick über die Architektur von ViPER gegeben, dann werden die wesentlichen Funktionen der einzelnen ViPER-Komponenten erläutert.   Anschließend wird die Methodenunterstützung für MeDUSA (ViPER MetiS) im Detail betrachtet. Von besonderem Interesse ist hier die genutzte Technologie, mit der die Methodenunterstützung weitestgehend aus der Methodenbeschreibung generiert werden kann. Sogenannte Wizards unterstützen den Entwickler bei der Durchführung einzelner Aktivitäten und insbesondere beim Übergang von einem Arbeitsbereich zum darauffolgenden. Dies wird am Beispiel der Identifikation von Subsystemen auf Basis des Analysemodells und der Generierung von Code auf Basis des Entwurfsmodells gezeigt. Als Beispiel für eines der vielen technischen Details sei hier das implementierte Traceability-Rahmenwerk erwähnt, das es erlaubt, die Abbildungen einzelner Modellelemente über die verschiedenen MeDUSA UML-Modelle nachzuvollziehen.   Teil 3: Evaluation & Conclusion In den Kapiteln 9 und 10 werden die Methode und die erstellte Werkzeugumgebung bewertet. Zuerst wird vorgestellt, in welchen Stufen die Methode MeDUSA entwickelt bzw. weiterentwickelt wurde. Dabei wird auf die in Fallstudien und in Pilotprojekten gemachten praktischen Erfahrungen eingegangen und erläutert, wie die negativen und positiven Erfahrungen in die Evolution der Methode eingeflossen sind. Um die Werkzeugumgebung ViPER zu bewerten, werden einige architektur‐ und codebasierte Metriken vorgestellt und diese interpretiert. Weiterhin wird der implementierte ViPER-Entwicklungsprozess beschrieben, der aufgrund der häufigen Integrationen und Testläufe zur Qualität der Werkzeugumgebung beigetragen hat. Abschließend werden einige interessante Aspekte diskutiert, die in dieser Arbeit nicht behandelt wurden, und Raum für weitere Arbeiten bieten.   Kontakt: any _at_ informatik.rwth-aachen.de