ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0

Größe: px

Ab Seite anzeigen:

Download "ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0"

Daniel Meinhardt
vor 8 Jahren
Abrufe

1 Jens Kohlmeyer 05. März 2007 Institut für Programmiermethodik und Compilerbau ActiveCharts Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0

2 Seite 2 Übersicht Unser Ansatz ActiveCharts kombiniert Modelle aus den Analyse/Design- Phasen und (handgeschriebenen) Code aus der Implementierungsphase auf eine neue Art: Der Kontrollfluss einer Anwendung wird mit UML 2.0 Aktivitätsdiagrammen modelliert, die von einer Laufzeitumgebung (ActiveChartsIDE) interpretiert werden. Mit dieser Laufzeitumgebung können die Aktivitätsdiagramme simuliert und visualisiert werden. Funktionen wie beispielsweise Breakpoints oder schrittweises Vorgehen ermöglichen ein einfaches Debuggen der Anwendung. Analyse- bzw. Designartefakte werden in unserem Ansatz nahtlos für die Implementierungsphase übernommen. Wir wollen damit die Lücken zwischen den unterschiedlichen Phasen im Softwareentwicklungsprozess verkleinern und die Dokumentation und die Wartbarkeit von Softwareprodukten verbessern.

Mit dieser Laufzeitumgebung können die Aktivitätsdiagramme simuliert und visualisiert werden.

3 Seite 3 Inhalt Motivation Forschungsansatz ActiveCharts ActiveCharts Architektur Beispiel Diskussion Aktuelle Forschungsarbeiten Zusammenfassung und Ausblick

4 Seite 4 Motivation (1/2) Probleme bei der Softwareentwicklung - Lücke zwischen Design-Phase und Implementierung - Modelle werden nicht wieder verwendet - Modellinhalte müssen nachimplementiert werden - Dokumentation ist unter Umständen nicht aktuell - Die Semantik von verwendeten Modellen ist oft unklar - Freie Auslegung durch Entwickler kann zu falscher Implementierung führen - Fehlende Ausführbarkeit der Modelle kann zu falschem Verhalten führen Ein Lösungsansatz: Model Driven Architecture, MDA - Idee: Lücke zwischen Design-Phase und Implementierung schließen - Anwendungen aus Modellen (und nötigen Erweiterungen generieren) - Wiederverwendung der Business-Logik durch plattformunabhängige Modelle (PIM) - Erzeugung von plattformspezifischem Code durch entsprechende Modelle (PSM)

Ausführbarkeit der Modelle kann zu falschem Verhalten führen Ein Lösungsansatz: Model Driven Architecture, MDA - Idee: Lücke zwischen Design-Phase und Implementierung schließen - Anwendungen aus

5 Seite 5 Motivation (2/2) Zwei Hauptinterpretationen der MDA: Translationist PIM Elaborationist PIM PSM PSM: Code PSM: Code

6 Seite 6 Forschungsansatz ActiveCharts ein MDA-Ansatz (1/2) 1. Reines Forward Engineering - Beschreiben der statischen Struktur mit UML 2.0 Klassendiagrammen - Beschreiben des Verhaltens mit UML 2.0 Aktivitätsdiagrammen - Modellieren den Kontrollfluss der Anwendung - Werden zur Laufzeit interpretiert 2. Verknüpfung mit herkömmlicher objektorientierter Programmiersprache - C# - Aktionen aus den Aktivitätsdiagrammen können mit C# Code ausgearbeitet werden

0 Klassendiagrammen - Beschreiben des Verhaltens mit UML 2.

7 Seite 7 Forschungsansatz ActiveCharts ein MDA-Ansatz (2/2) Analyse/Design Domänenmodell (Klassendiagramm) Anwendungsfälle (Text) Aktivitätsdiagramme (Erweiterungen der Anwendungsfälle) Simulation & Debugging mit ActiveChartsIDE Implementierung Codegenerierung aus dem Domänenmodell Interfaces aus dem Aktivitätsdiagramm generieren Interfaces implementieren (die Aktionen) Diagramme werden durch Laufzeitumgebung ausgeführt Test Simulation & Debugging mit ActiveChartsIDE Release Standalone execution des Projekts

Codegenerierung aus dem Domänenmodell Interfaces aus dem Aktivitätsdiagramm generieren Interfaces implementieren (die Aktionen)

8 Seite 8

9 Seite 9 Inhalt Motivation Forschungsansatz ActiveCharts ActiveCharts Architektur Beispiel Diskussion Aktuelle Forschungsarbeiten Zusammenfassung und Ausblick

10 Seite 10 Ein Beispiel eine vereinfachte Alarmanlage Alarmanlage - hat Sensoren, Sirenen und einen Controller - Sensoren senden Heartbeat-Signal - Wird der Heartbeat nicht innerhalb einer bestimmten Zeit empfangen: Alarm!

Controller - Sensoren senden Heartbeat-Signal - Wird

11 Seite 11

12 Seite 12 Vereinfachte Alarmanlage statische Struktur AlarmDeviceController 1 device 1..* sensors Sensor device sirens 1 1..* Siren Generator C# Code, der die Klassen, Attribute und Assoziationen implementiert Verwendung in eigenem Code AlarmDevice alarmanlage = new AlarmDevice(); Siren sirene = new Siren(); alarmanlage.sirenen.add(sirene);

.* Siren Generator C# Code, der die Klassen, Attribute und Assoziationen

13 Seite 13

14 Seite 14 Alarmanlage - Kontrollfluss SensorBehavior ControllerBehavior Init 5s Heartbeat receivedsignal Heartbeat 10s ProcessHeartbeat Alarm result [result == true] [result == false]

15 Seite 15 Alarmanlage - Kontrollfluss SensorBehavior ControllerBehavior Init 5s Heartbeat receivedsignal Heartbeat 10s ProcessHeartbeat Alarm result [result == true] [result == false]

16 Seite 16 Alarmanlage - Kontrollfluss SensorBehavior ControllerBehavior Init 5s Heartbeat receivedsignal Heartbeat 10s ProcessHeartbeat Alarm result [result == true] [result == false]

17 Seite 17 Alarmanlage - Kontrollfluss SensorBehavior ControllerBehavior Init 5s Heartbeat receivedsignal Heartbeat 10s Programmiert mit C# Code ProcessHeartbeat Alarm result [result == true] [result == false]

18 Seite 18

19 Seite 19 Handgeschriebener Code ProcessHeartbeat muss überprüfen, ob ein Sensor fehlt Für alle existierenden Sensoren die Zeitstempel anschauen Falls ein Sensor keinen Heartbeat mehr sendet, Alarm auslösen Für den Sensor, der das Signal gesendet hat: Zeitstempel aktualisieren

anschauen Falls ein Sensor keinen Heartbeat mehr sendet, Alarm

20 Seite 20 ActiveCharts Sreenshots (1/2)

21 Seite 21 ActiveCharts Sreenshots (2/2)

22 Seite 22 Diskussion Die erstellten Analyse/Design-Dokumente sind Teil der Implementierung Wiederverwendung der Design-Artefakte Die graphische Dokumentation ist immer aktuell Kein unnötiges Nachprogrammieren des Kontrollflusses Die Modelle könne ausgeführt werden Wohldefinierte Semantik Explizite Schnittstelle zwischen PIM und PSM/Code (Aktionen) Verwendung einer herkömmlichen Programmiersprache (C#) Verhältnis von Code und Modellen ist frei wählbar Erhöht die Akzeptanz beim Entwickler Vereinfacht den Übergang zu modellgetriebener Softwareentwicklung Formale Beschreibung der Semantik von Aktivitätsdiagrammen der UML 2.0 mit Abstract State Machines

23 Seite 23 Aktuelle Forschungsarbeiten - Einbindung von (nichtfunktionalen) Anforderungen in ActiveCharts - Übersetzungsansatz: übersetzte Komponenten einbinden - Persistierung des Interpreters (beispielsweise für Testsuite) - Generierung von Testfällen - Portierung auf Java - Wohldefinierte Semantiken für weitere UML 2.0 Diagrammarten (Abstract State Machines) - Verifizierung von Abstract State Machines

24 Seite 24 Zusammenfassung und Ausblick - Unser Ansatz der modellgetriebenen Softwareentwicklung benutzt UML 2.0 Klassen- und Aktivitätsdiagramme - ActiveChartsIDE unterstützt in diesem Ansatz: - Import der erstellten Diagramme - Codegenerierung aus Klassendiagrammen - Interpretation der Aktivitätsdiagramme zur Laufzeit - Visualisierung des Tokenflusses - Debugger Funktionalität - Formale Beschreibung der Semantik mit Abstract State Machines Weitere Informationen und ActiveChartsIDE-Download unter

25 Seite 25 Vielen Dank für Ihre Aufmerksamkeit!

Ähnliche Dokumente

Copyright 2014 Delta Software Technology GmbH. All Rights reserved.

Copyright 2014 Delta Software Technology GmbH. All Rights reserved. Karlsruhe, 21. Mai 2014 Softwareentwicklung - Modellgetrieben und trotzdem agil Daniela Schilling Delta Software Technology GmbH The Perfect Way to Better Software Modellgetriebene Entwicklung Garant für