Modernisierung eines Legacysystems mittels MDSD

Transkript

1 Modernisierung eines Legacysystems mittels MDSD Tim Gesekus, Ralph Kar ATM Simulator Centre Research & Development DFS Deutsche Flugsicherung GmbH Tim Gesekus & Ralph Kar, OOP 2010

2 Inhalt Vorstellung Problemstellung Lösungsansätze Technische Umsetzung Lessons Learned Tim Gesekus & Ralph Kar, OOP

3 Deutsche Flugsicherung GmbH Tim Gesekus & Ralph Kar, OOP

4 Vorstellung ATM Simulator Zentrum Eingebettet in Forschung und Entwicklung Entwurf, Erstellung, Wartung und Betrieb von Realzeit- und Schnellzeit- Flugsicherungssimulatoren Erstellung von Prototypen für Forschungszwecke Beschäftigt ca. 40 Mitarbeiter, davon 10 SW- Entwickler Bau von Simulatoren seit 15 Jahren Forschung Training FS-Dienste Tim Gesekus & Ralph Kar, OOP

5 Vorstellung Installationen Tim Gesekus & Ralph Kar, OOP

6 Vorstellung NEWSIM Realzeitsimulator zur Streckenkontrolle Hauptsächlich genutzt zu Aus- und Weiterbildung Tim Gesekus & Ralph Kar, OOP

7 Problemstellung Motivation für die Modernisierung 1 Simulator erfreute sich wachsender Beliebtheit beim Kunden Anforderungen nahmen zu, aber... Es wurde immer teurer und unkalkulierbarer, neue Features einzubauen Auswirkung von Refactoring war nicht überschaubar und wurde deswegen nicht gemacht Qualität verschlechterte sich Sehr hoher Einarbeitungsaufwand für Entwickler Simulator entwickelte sich zum ungeliebten Kind der Entwickler und Verantwortung wurde abgelehnt Tim Gesekus & Ralph Kar, OOP

8 Problemstellung Motivation für die Modernisierung 2 Historisch gab es einen Trainings- und einen Forschungssimulator Es gab zwei Displaysysteme (ILOG Views/C++ und Java) Systemdopplung bindet Ressourcen und verhindert Synergien Tim Gesekus & Ralph Kar, OOP

9 Problemstellung Architektur und Design Keine klare Trennung der Zuständigkeit und Schichten Typenlose Datenstrukturen bis in die Fachlogik Kein einheitliches Speichermanagement Struktur des Fachmodells über viele Orte im Quellcode verteilt Letztlich eine massive Erosion der Architektur Tim Gesekus & Ralph Kar, OOP

10 Problemstellung Wo wollten wir hin? SW-Architektur Harmonisierung der Simulatorplattform Wiederverwendbarkeit erhöhen Einarbeitungszeit verringern Klare Trennung der Schichten Strategischer Nutzen für den Forschungsbereich Pflegeaufwand verringern und Willen zur Pflege stärken Produktivität steigern Frustfaktor der Entwickler senken Flexibilität wieder herstellen Tim Gesekus & Ralph Kar, OOP

11 Lösungsansätze Welche Lösungen gab es? Komplett neu implementieren (Reengineering) + Chance für ordentliche Architektur + Chance, gemachte Fehler nicht noch einmal zu machen - Aus Kundensicht: langer Stillstand Weiterentwicklung stoppen und Software refaktorieren + Notwendige Aufräumarbeiten werden erledigt - Kunde bekommt keine neuen Features - Architekturänderungen erst gegen Ende möglich Während der Wartung refaktorieren + Zeit zur Analyse und Einarbeitung + Kein Stillstand aus Kundensicht - Architekturänderungen erst gegen Ende möglich Tim Gesekus & Ralph Kar, OOP

12 Lösungsansätze NEWSIM Prozesssicht Simulations Treiber Flugplandaten Verarbeitung Display NEWSIM Display (Java) Atcoach (UFA) NEWSIM Kern (C++) NEWSIM Display (Java) NEWSIM Display (Java) Daten Tim Gesekus & Ralph Kar, OOP

13 Lösungsansätze Welche Lösung haben wir gewählt? Display neu machen Lizenzmodell von ILOG Views passt nicht in unser zukünftiges Geschäftsmodell Java als strategische Entscheidung Altes Java Display war nicht mehr zu retten Kern während der Wartung refaktorieren Kunde erwartet Updates Für eine Neuimplementierung war die Anforderungslage zu undurchsichtig Die Fachlogik war korrekt und sollte erhalten bleiben Aufwand einer Neuimplementierung war nicht abschätzbar Tim Gesekus & Ralph Kar, OOP

14 Technische Umsetzung So ging es los Modellierung der vorhandenen Fachklassen in UML Erstellen der Generatoren Ersetzen der handgeschriebenen Fachklassen durch generierte Fachklassen Implementierung des in C++ vorhandenen Frameworks für Distribution und Notifizierung in Java Fachlogik Fachmodell Distributionslogik Notifizierung Fachlogik/Modell Notifizierungs Framework Distributions Framework Tim Gesekus & Ralph Kar, OOP

15 Technische Umsetzung Tool Chain mit Magic Draw Magic Draw Open Architecture Ware XMI Export Xtend Xpand Java Code Fach Modell M2M Distribution Notify Modell M2T Modell zu Modell Transformation Modell zu Text Transformation C++ Code Tim Gesekus & Ralph Kar, OOP

16 Technische Umsetzung Wechsel von UML nach Xtext Warum ein Wechsel UML Tool hat hohe Lernkurve Nicht alle Funktionen des Tools wurden genutzt Zusammenarbeit in UML Tool war schwierig (Branchen, Mergen) Sehr viele Informationen in Stereotypen/Tagged Values Medienbruch für Entwickler Warum Xtext Xtext ist ein Open-Source-Framework für die Entwicklung von textbasierten, domänenspezifischen Sprachen Kleine Lernkurve in der Anwendung (Texteditor kennt jeder) Kein Medienbruch Passt zum Rest von OAW Migration war einfach (2 Tage Aufwand) Tim Gesekus & Ralph Kar, OOP

17 Technische Umsetzung Tool Chain mit Magic Draw Magic Draw Open Architecture Ware XMI Export Xtend Xpand Java Code Fach Modell M2M Distribution Notify Modell M2T Modell zu Modell Transformation Modell zu Text Transformation C++ Code Tim Gesekus & Ralph Kar, OOP

18 Technische Umsetzung Tool Chain mit Xtext Open Architecture Ware Xtext Xtend Xpand Java Code Fachmodell M2M Distribution Notify Modell M2T Modell zu Modell Transformation Modell zu Text Transformation C++ Code Tim Gesekus & Ralph Kar, OOP

19 Technische Umsetzung Fachmodelltransformation 1 NEWSIM Kern Model Transformer NEWSIM Display NEWSIM Modell NEWSIM ATM ATM Modell Modell Modell Tim Gesekus & Ralph Kar, OOP

20 Technische Umsetzung Fachmodelltransformation 2 NEWSIM Kern NEWSIM Display ATM Modell (C++) ATM Modell (Java) Tim Gesekus & Ralph Kar, OOP

21 Lessons Learned Wo sind wir heute? Das komplette Fachmodell wird generiert Die Einarbeitungszeit ist von mehreren Monaten auf wenige Tage gesunken Neue Funktionalitäten können schnell integriert werden und auch vernünftig getestet werden Der handgeschriebene Code wurde um fast 30% reduziert, bei Zuwachs der Funktionen Unsere Abschätzungen für Features sind erheblich besser geworden Tim Gesekus & Ralph Kar, OOP

22 Lessons Learned Wo wollen wir hin? MGIT Zyklus (Modellieren Generieren Implementieren Testen) muss etabliert und gefestigt werden Stärkere Ausrichtung an einer Komponenten Architektur Nutzung eines IOC Containers Leichtere Wiederverwendbarkeit in anderen Applikationen Modellierung weiterer Anbindungen im Rahmen einer Harmonisierung mit Hilfe des ATM Modells Migration vom alten Modell zum einheitlichen ATM Modell Framework kann durch ein COTS Produkt ausgetauscht werden (dies geht weitestgehend mit einer Änderung im Generator einher) Tim Gesekus & Ralph Kar, OOP

23 Lessons Learned Was lief schlecht? Wir haben uns furchtbar verschätzt (nicht MDSD, sondern Legacy System war schlimmer als gedacht) Entwicklung von temporären Modulen Ein Coach hätte sicherlich am Anfang gut getan Am Ende doch 2 Monate Stillstand Tim Gesekus & Ralph Kar, OOP

24 Lessons Learned Was lief gut? Generator und Framework werden in mehreren Projekten verwendet (Sinatra) Durch Modellierung wurde eine gemeinsame Sprache gefunden Umstellung auf Komponenten Architektur wird ermöglicht Große Akzeptanz des MDSD Ansatzes im Team Embracing Change Testbarkeit hat sich stark verbessert Tim Gesekus & Ralph Kar, OOP

25 Vielen Dank für Ihr Interesse! Tim Gesekus & Ralph Kar, OOP