Dr. Christoph Niemann otris software AG Königswall 21 44137 Dortmund niemann@otris.de Tel. 0231/958069-0 www.otris.de Modellgetriebene Software- Entwicklung: Wunsch oder Wirklichkeit? copyright by otris software AG: Vervielfältigungen auch auszugsweise nur durch die schriftliche Genehmigung der otris software AG
Übersicht Modellgetriebene Software-Entwicklung: Wunsch Modellgetriebene Software-Entwicklung: Unser Ansatz Die Pflege modellgetrieben entwickelter Anwendungen Muss das sein? Halten des Abstraktionsniveaus Weiterentwicklung des Generators Maximieren des generierten Codes
Übersicht Modellgetriebene Software-Entwicklung: Wunsch Modellgetriebene Software-Entwicklung: Unser Ansatz Die Pflege modellgetrieben entwickelter Anwendungen Muss das sein? Halten des Abstraktionsniveaus Weiterentwicklung des Generators Maximieren des generierten Codes
Modellgetriebene Software-Entwicklung: Wunsch Fachliche Informationen werden auf einem sehr hohen Abstraktionsniveau modelliert Fachexperten können solche Modelle lesen und beurteilen Technische Aspekte werden durch angepasste Transformationen in ein technisches Modell eingebaut Technische Experten arbeiten weitgehend unabhängig von den Fachexperten an dieser Aufgabe Generatoren erzeugen aus dem technischen Modell große Teile der Anwendung.
Modellgetriebene Software-Entwicklung: Wunsch Zusammenfassend: Anwendungen einer Familie lassen sich sehr leicht entwickeln, wenn das erste Mitglied erst einmal auf der Welt ist
Übersicht Modellgetriebene Software-Entwicklung: Wunsch Modellgetriebene Software-Entwicklung: Unser Ansatz Die Pflege modellgetrieben entwickelter Anwendungen Muss das sein? Halten des Abstraktionsniveaus Weiterentwicklung des Generators Maximieren des generierten Codes
Modellgetriebene Entwicklung: Unser Ansatz JANUS: Entwickelt seit 1994 am Lehrstuhl für Software-Technik unter Leitung von Prof. Balzert Ziele: Vollständige Generierung lauffähiger Anwendungen aus fachlichen Modellen Weiterentwicklung der generierten Anwendung zum Produkt möglich
Modellgetriebene Entwicklung: Unser Ansatz Damaliger Ansatz: Fokussierung auf die Software-Family Kaufmännisch/Administrative Anwendungen unter Berücksichtigung der technischen Domains GUI, Web- GUI, Datenbank, Client/Server-Verteilung, Mandantenfähigkeit, Mehrbenutzerfähigkeit, Mehrsprachigkeit Einbettung in handelsübliches UML-Werkzeug OOA-Modell als Platform Independent Model Transformation in Platform Specific Model geschieht implizit Generierung von C++
Modellgetriebene Entwicklung: Unser Ansatz Analyse Generierung Idee Modell Pilotsystem Customer CustomerNo : Serial Name : String<40> Address : String<100> ZipCode : String<7> City : String<30> Contact : PersonT / WriteAccess : Boolean 1 0.. n Offer OfferNo : Serial Valid from : Date = current Valid until : Date / Total : Currency / Value Added Tax : Currency / Amount : Currency Remarks : Text $ VatRate : Unsigned Short = 16 / valid : Boolean Print() 1 1..n Item ItemNo : Unsigned Short Quantity : Float = 1 / Cost per Quantity : Currency / Cost : Currency Product ProductNo : Serial Name : String<40> Unit of Quantity : UnitOfQuantityKind = Piece Cost per Quantity : Currency = 0 Specific ation : String<120> Length : Float W idth : Float Height : Float Capacity : Float Licens etype : LicenseTypeET = Node Locked HourType : HourTypeET = Real (60 min)
Modellgetriebene Entwicklung: Unser Ansatz Gemeinsamkeiten mit MDSD/MDA Abstraktes fachliches Modell Konzentration auf eine Software-Familie Inkrementelle Entwicklung ist der bevorzugte Weg Verwendung derselben Notation Die Philosophie ist dieselbe
Modellgetriebene Entwicklung: Unser Ansatz Unterschiede zu MDA Architektur ist vorgegeben und lässt sich in Grenzen parametrisieren Einzelplatz vs. Client/Server Web-Anwendung und/oder Rich Client Unix/Windows Transformation direkt aus dem PIM Das PIM wird um Domain-Informationen angereichert z.b. zum GUI und/oder Datenbank
Modellgetriebene Entwicklung: Unser Ansatz
Modellgetriebene Entwicklung: Unser Ansatz Unterschiede zu MDA Inkrementelle Entwicklung wird stärker betont, da erste Pilotsysteme bereits nach kurzer Modellierungszeit generiert werden können Umfangreiche auf den Anwendungsbereich Kaufmännisch/Administrative Anwendungen zugeschnittene Laufzeitumgebung zur Unterstützung der manuellen Implementierung
Modellgetriebene Entwicklung: Unser Ansatz Mögliche Architektur der JANUS-Anwendung
Übersicht Modellgetriebene Software-Entwicklung: Wunsch Modellgetriebene Software-Entwicklung: Unser Ansatz Die Pflege modellgetrieben entwickelter Anwendungen Muss das sein? Halten des Abstraktionsniveaus Weiterentwicklung des Generators Maximieren des generierten Codes
Pflege modellgetrieben entwickelter Anwendungen Muss das sein? Natürlich, denn der Grund für Software-Pflege liegt ja nicht im Entwicklungsprozess, sondern In sich ändernden fachlichen Anforderungen In sich ändernden technischen Anforderungen Aber: Änderungen der technischen Anforderungen können fast ausschließlich in den Generatoren (und damit nur 1x) umgesetzt werden.
Pflege modellgetrieben entwickelter Anwendungen Halten des Abstraktionsniveaus Die Höhe des Abstraktionsniveau ist entscheidend für die Effizienz des Pflegeprozesses Für die Pflege ist das Werkzeug entscheidend
Pflege modellgetrieben entwickelter Anwendungen Weiterentwicklung des Generators Weiterentwicklungen der Generatoren (seien es eigene oder zugekaufte) kommen den gepflegten Anwendungen direkt zu gute. Beispiele: Integration einer Scripting-Engine Integration von XML-Export/Import Anschluss neuer Datenbank-Systeme Unterstützung neuer Plattformen Bugs, die in einem Projekt entdeckt wurden, sind überall gefixt
Pflege modellgetrieben entwickelter Anwendungen Maximieren des generierten Codes Welche manuell implementierten Teile sollten verallgemeinert werden? Ziel: Weiterentwicklung des Generators aus konkreten Projektanforderungen Beispiele für solche Erweiterungen Mandantenfähigkeit Höherer Sicherheitsstandard bei Mehrbenutzerverwaltung Export/Import-Schnittstellen Wizards
Projekte in der Pflegephase Projekt: Riester-Rente Produkt: Software zum Risiko-Management
Projekt: Riester-Rente Beginn der Entwicklung: 2001 Anwendung zur Unterstützung des Zertifizierungsprozesses für Riester-Renten -Verträge Mehrbenutzerfähige Client/Server-Anwendung mit Rich Client In Pflege seit 2002 2001 2006 Fachklassen 27 30 Generierte LOC 109.236 131.321 Manuelle LOC 9.823 12.647
Projekt: Riester-Rente
Pflege im Projekt Riester-Rente Umstellung der Plattform Server: Windows NT -> Sun Solaris Clients: Windows NT -> Windows XP Aktion: Neugenerierung für Umstellung auf neues Look & Feel (Client) und neues Betriebssystem (Server) Weniger Aufwand, als bei herkömmlicher Pflege Ändern des Rollenkonzepts Benutzer können mehrere Rollen gleichzeitig annehmen Aktion: Änderung des fachlichen Modells, Leichte Anpassungen im Code, Neugenerierung
Pflege im Projekt Riester-Rente Gesetzesänderungen Änderungen im Zertifizierungsprozess Erweiterungen im Objektmodell Wenig manuelle Kodierung, da meist nur Vertragseigenschaften hinzugefügt werden wie z.b. Geschlechtsneutrale Verrentung Vergessene Use-Cases Z.B.: Fusion von Banken Möglichst wenig Änderungen im Objektmodell Manuelle Kodierung z.b. für Datenmigration
Produkt: R2C Beginn der Entwicklung: 2000 Software für das Management von Geschäftsrisiken von Kapitalgesellschaften Mehrbenutzerfähige Client/Server-Anwendung mit Rich- Client und Web-Client; umfangreiches Reporting Kontinuierliche Weiterentwicklung bis heute Produktinfos: http://www.schleupen.de 2000 2006 Fachklassen 48 134 Generierte LOC 215.000 600.000 Manuelle LOC 31.213 83.232
Produkt: R2C
Produkt: R2C
Pflege im Produkt R2C Erweiterung der Funktionalität Umfangreiche Modelländerungen Zusätzlicher Code Erweiterung des Generators, um den manuellen Code- Anteil gering zu halten Entwicklung einer Web-Oberfläche zusätzlich zum Rich-Client Spezifikation der Web-Oberfläche im Modell Spezifikation von HTML-Sichten
Pflege im Produkt R2C Unterstützung weiterer Datenbanken Erweiterung des Generator-Lizenz Erstellen einer Light -Version Nutzung eines anderen Generierungsschema (Einzelplatzanwendung) Ausblenden von Funktionalität im Modell durch Skripting des Modells
Pflege: Zusammenfassung Eigentlich handelt es sich um eine Fortsetzung des inkrementellen Entwicklungsprozesses nur mit größeren Abständen zwischen den Inkrementen Fachliche Änderungen müssen im PIM umgesetzt werden, damit das Abstraktionsniveau erhalten bleibt Technische Änderungen werden eher im Generator bzw. den technischen Modellen umgesetzt.
Pflege: Zusammenfassung Probleme können auftreten, wenn die verwendeten Werkzeuge nicht mehr gepflegt werden Was ein generelles Problem bei der Benutzung proprietärer Software ist. Die technische Qualität hängt fast nur von der Qualität des Generators ab Die Effizienz der Entwicklung bleibt bestehen, wenn der Entwicklungsprozess bestehen bleibt und wenn modellgetrieben gepflegt wird.
Pflege: Zusammenfassung Fehler werden nur einmal gemacht Fast immer
Vielen Dank für Ihre Aufmerksamkeit! niemann@otris.de otris software AG Königswall 21 44137 Dortmund www.otris.de