Inhaltsübersicht. n Aufgabenstellung. n Lösungsüberblick. n Herausforderungen. n Entwicklung der Generatoren. n Zusammenfassung/Schlussfolgerungen

Transkript

1 Dr. Christoph Niemann otris software AG Königswall 21 D Dortmund Tel. +49 (0) Modellgetriebene Entwicklung eines WLAN-Management- Systems copyright by by otris software AG: Vervielfältigungen auch auszugsweise nur nur durch die die schriftliche Genehmigung der der otris software AG AG

2 Inhaltsübersicht n Aufgabenstellung n Lösungsüberblick n Herausforderungen n Entwicklung der Generatoren n Zusammenfassung/Schlussfolgerungen

3 Aufgabenstellung n Entwicklung eines Software-Systems, mit dem sich WLAN-Geräte (Access-Points) des Herstellers Funkwerk konfigurieren und managen lassen n Skalierbar von 2 bis mehrere Access-Points n Teile der Software laufen auf den Access-Points; Teile laufen auf dem Management-System n Mandantenfähig (Systemintegratoren betreuen mehrere Netze) n Mehrere Varianten der Software n Geringer Aufwand für Wartung und Pflege

4 WLAN Management Anwendungsfälle n Konfigurationsvorlagen: n Zentrales Management und Versionierung n Konfigurationsprofile für verwaltete Objekte (WLAN-Modul, WLAN-AP-Port, WLAN-Bridge-Port, etc.) n Konfigurations-Jobs: n Flexible Zeitsteuerung (wann?) Einmalig: heute um 13:00 Uhr Periodisch: jeden Tag, jede Stunde, außer an Feiertagen n Verschiedene Aktionen (was?) Erzeugen, Ändern, Löschen von Objekten Firmware Download Reboot n Flexible Filter / Auswahlkriterien für Objekte (wo?) alle 2,4 GHz Zellen der Organisation alle Gastzugänge mit WPA-PSK Sicherheit alle APs im Standort Berlin n Jobüberwachung mittels definierbarer Ereignisse

5 Lösungsüberblick n Entstanden ist ein System aus vier Komponenten: n Client: dotnet-anwendung mit generierten Dialogen n Server: C++-Anwendung mit generierten FK-Klassen und DB-Anbindung n Access-Points: Firmware mit eigener DSL zur Konfiguration n Product-Designer: Spezifizieren neuer Produkte mit UML

6 Lösungsüberblick: Projektumfang n Entwicklungsdauer n ca. 50 MM inklusive Generatoren n Anzahl Klassen im PIM: 170 n Anzahl LOC n Gesamt: ca. 2 Mio. n Davon manuell erstellt: C++, C#

7 Lösungsüberblick: Architektur der Lösung WiLMA Use Cases Roll Out Mgmt Config Mgmt Monitoring Reporting Policy Mgmt. Object Model with Device Inventory and Managed Objects WiLMA Database NMF MO - API Object Mapping Other Mgmt RPC MOF IP Network (LAN / WAN) Managed Objects Framework Script Generator/Receiver Product Designer RPC Mechanism (TR-069) RPC CMI FEC Device Embedded Objects

8 Lösungsüberblick Client

9 Inhaltsübersicht n Aufgabenstellung n Lösungsüberblick n Herausforderungen n Entwicklung der Generatoren n Zusammenfassung/Schlussfolgerungen

10 Herausforderungen: Erweiterbarkeit n Herausforderung n Unterstützung von mehreren Dutzend Produkten in allen heute und künftig verfügbaren SW-Versionen mit minimalem Pflegeaufwand n Die Idee n Definition der gerätespezifischen Eigenschaften in einem eigenen Metamodell n Erstellung der Metadaten durch Gerätehersteller n Die Lösung n Der Product-Designer

11 Herausforderungen: Wartbarkeit n Herausforderung n Der Auftraggeber möchte selbst in der Lage sein, die Anwendung zu warten und weiterzuentwickeln n Die Idee n Angepasste Generatoren/DSLs/Frameworks für die verschiedenen Teilkomponenten Embedded Device, Server, Client, Product-Designer n Die Lösung n JANUS-Generator wird für die verschiedenen Szenarien angepasst n Neue Generatoren werden entwickelt und teilweise in die Anwendung integriert.

12 Herausforderungen: Skalierbarkeit n Herausforderung n Für die verschiedenen Zielgruppen werden unterschiedlich leistungsfähige Varianten derselben Software benötigt n Die Lösung n Durch Spezifikationsänderungen am Modell werden die verschiedenen Varianten generiert.

13 Herausforderungen: Kommunikation n Herausforderung n Die zu konfigurierenden Geräte sind oft hinter einer Firewall und verwenden nicht-öffentliche IP-Adressen n Die Lösung n Die Kommunikation zwischen den Geräten und dem Server erfolgt über TR-069, d.h. die zu konfigurierenden Geräte schicken regelmäßig http-anfragen an die Zentrale und bitten um Anweisungen WAN Home Office Remote Site

14 Herausforderungen: Generatoren n Herausforderung n Es soll möglichst viel des vorhandenen JANUS- Generators verwendet werden, um die Entwicklung möglichst kostengünstig durchführen zu können. n Die Embedded-Geräte verfügen nur über sehr begrenzte Ressourcen und benötigen hoch optimierten Code n Die Lösung n Auf den Embedded-Geräten läuft ein kleiner Interpreter, der von der Anwendung zur Laufzeit generierten Code ausführt

15 Herausforderungen: Team n Herausforderung n Das WiLMA-Team besteht auf Software-Entwicklern von Auftragnehmer (Server, Client, Generatoren) und Auftraggeber (Embedded-Geräte) n Die Lösung n Vertrauen, da Quellcode gegenseitig ausgetauscht werden muss n Trennen der Entwicklung in Generatoren, Framework/DSLs und eigentliche Anwendung

16 Inhaltsübersicht n Aufgabenstellung n Lösungsüberblick n Herausforderungen n Entwicklung der Generatoren n Zusammenfassung/Schlussfolgerungen

17 Entwicklung der Generatoren n Product-Designer n Im Product-Designer werden die von WiLMA zu verwaltenden Geräte mit Hilfe eines eigenen Profils in UML spezifiziert. n Zusätzliche Geräteeigenschaften können über einen speziellen Editor gepflegt werden. Speicherung erfolgt als Tagged Values im UML-Modell n Entwickelt als JANUS-Anwendung n Zielgruppe: Hersteller von zu konfigurierenden Geräten

18 Entwicklung der Generatoren n Product-Designer

19 Entwicklung der Generatoren n Generatoren für Server-Funktionalität n Weitgehend unverändert aus dem JANUS-Generator übernommen n Integration der Funkwerk-API zur Kommunikation mit den Endgeräten

20 Entwicklung der Generatoren: JANUS n Modellieren eines fachlichen Modells n JANUS-spezifische Informationen hinzufügen n Generieren n Eigenen Code hinzufügen n Sehr inkrementell n Ausführbare Anwendung von Anfang an

21 Entwicklung der Generatoren n Generatoren für Client-Funktionalität n Einfache Dialoge basieren ebenfalls auf JANUS n Für komplexere Dialoge wird lediglich eine XML- Beschreibung generiert, die die Anbindung ans Fachkonzept realisiert und ein einfaches Layout zur Verfügung stellt Das Layout der Dialoge kann dann mit einem grafischen Editor gestaltet werden Generierte Dialoge lassen sich Schritt für Schritt optimieren Die inkrementelle Vorgehensweise bleibt komplett erhalten

22 Entwicklung der Generatoren n Generatoren für die Access-Points n Auf den Access-Points läuft ein echtzeitfähiges Multiuser/Multitasking-Betriebssystem n Generierter Code darf die Stabilität des Systems nicht gefährden n Die Restriktionen in Bezug auf zur Verfügung stehende Rechenleistung und Speicher müssen beachtet werden

23 Entwicklung der Generatoren n Generatoren für Access-Points n Für die Access-Points wurde ein Interpreter entwickelt, der Skripte verarbeitet, die Konfigurationen auslesen/anwenden sowie Status-Informationen ermitteln können n Für den eigentlichen Server wurde ein Generator entwickelt, der die Konfigurationsskripte aus den Benutzereingaben generiert und an einen oder viele Access-Points überträgt n Die Generierung der Skripte erfolgt unter Kenntnis der mit dem Product-Designer erstellten Gerätebeschreibung, d.h. unterschiedliche Geräte werden mit verschiedenen Skripten bedient.

24 Inhaltsübersicht n Aufgabenstellung n Lösungsüberblick n Herausforderungen n Entwicklung der Generatoren n Schlussfolgerungen/Ausblick

25 Zusammenfassung/Schlussfolgerungen n Ergebnis der Entwicklung n WiLMA ist seit Mitte 2008 verfügbar n Version 1.1 befindet sich in der Entwicklung und kommt Mitte 2009 auf den Markt n Kombination verschiedener Generatoren bzw. umfassender APIs inklusive eigener DSL hat sich bewährt. n Neue Hardware-Modelle konnten ohne Änderung der Software unterstützt werden

26 Zusammenfassung/Schlussfolgerungen n Schlussfolgerungen n Entwicklung angepasster/eigener Generatoren lohnt sich besonders mit Blick auf die Wartungsphase n Ändern der Zielplattform mit bestehendem Generatorsystem ist durchaus möglich. Hier: Von C++/MFC für das GUI auf C#/dotNet. n Auch komplexe/sehr heterogene Anwendungen lassen sich mit MDD in kleinen Teams entwickeln. Größe des Teams: 7 Entwickler

27 Vielen Dank n n otris software AG Königswall Dortmund