Model Driven Software Development

Transkript

1 Model Driven Software Development Key Note DGLR Workshop, TUM Garching, 4. Oktober 2011 Dr. Björn Pötter Leiter SoftwareFactory (FCS & UAV Software), Cassidian (EADS)

2 Trends in der Softwareentwicklung (in der Luft- und Raumfahrtindustrie) Embedded Software Development ( Google hits) Model Driven Development ( Google hits) Software Quality ( Google hits) DO178B Software Considerations in Airborne Systems and Equipment Certification ( Google hits) ISO26262 Road Vehicles Functional Safety ( Google hits) CMMI ( Google hits) Agile Software Development ( Google hits)

3 Software Krise Die Software Krise ist 1968 auf einer NATO Konferenz verkündet worden (d.h. Software Projekte sind nicht in t,, Q ). Seit 1968 viele positive Entwicklungen (z.b. Software ist als Engineering Disziplin etabliert), allerdings ist die Situation weiterhin kritisch (s.r.) Wichtige Ursache ist Zunahme der Komplexität: Essentielle Komplexität (Größe des Produkts und der Organisation): kann nicht vermieden werden Zufällige Komplexität: kann kontrolliert werden, z.b. Kommunikation im Projekt, Agiles PM, Requirement Management, Unterstützung durch Tools Software Projekt Erfolg Jahre? Quelle: Standish Group Chaos Report (2006) Quelle: No Silver Bullet (F. Brooks, 1986)

4 Essentielle Komplexität: Größe der Software Software Krise Quelle: J.T. Foreman, SEI Presentation, Pitsburg, 2004

5 Aufwand & Kosten pro Prozessphase System Integration System Integration 17% Management 8% Other Softw are 3% Hardw are Softw are Integration 1% Softw are Integration Test 7% System Specification 25% System Spezifikation Low Level Softw are Test 17% Softw are Static Analysis 1% Softw are Implementation 10% Softw are Design 3% Review s and Inspections 8% Software Engineering Quelle: U York, HISE Group am Beispiel EF FCS

6 Ein Antwort auf Komplexität ist der Fokus auf Architekturen und Modelle Axiome: Separation of Concerns Begreifbarkeit Korrektheit und Vollständigkeit Ersetzbarkeit Prinzipien: Modularität Portabilität Formbarkeit / Veränderbarkeit Herstellbarkeit Konzeptionelle Integrität Abstraktion Lose Kopplung Hohe Kohäsion 10^0 Systeme 10^1 Domains 10^2 Packages 10^3 Classes 10^4 Fcts 10^5 LoC z.b.: UML-Modell

7 Modelgetriebene Softwareentwicklung Was uns Wikipedia verät Modellgetriebene Softwareentwicklung (englisch Model-Driven Software Development, kurz MDSD) ist ein Oberbegriff für Techniken, die automatisiert aus formalen Modellen lauffähige Software erzeugen. Dabei werden domänenspezifische Sprachen (englisch Domain-Specific Languages, kurz DSL) zusammen mit entsprechenden Codegeneratoren und Interpretern eingesetzt. Der ebenfalls häufig benutzte Begriff Model Driven Development (MDD), der ursprünglich von der OMG markenrechtlich geschützt war, wurde 2004 von dieser wieder frei gegeben. Ebenfalls verbreitet sind die synonymen Begriffe Model Driven Engineering (MDE) bzw. Model Driven Software Engineering (MDSE).

8 (Mögliche) Vorteile von modellgetriebener Softwareentwicklung Kosteneffizienz durch höhere Entwicklungsgeschwindigkeit und höhere Qualität: Fokus auf Modelle und Architekturen Separierung plattformspezifischer und plattformunabhängiger Anteile der SW Konzentration auf das Kundenproblem, statt auf das Implementierungsproblem Verwendung von Code Generatoren (CG) Konsistenz von Modell und Code Verringerter Testaufwand (qualifizierte CG) CG fangen Best Practice ein Arbeitsteilung: Modelle fangen das Domainwissen ein (Aufbau von Experten für Domainwissen) Einsatz der Top-Leute zur Entwicklung hochqualitativer, effizienter CG-Engine Verbesserte Dokumentation Vereinfachter re-use, falls o.g. Prinzipien befolgt werden

9 Eine gute Softwarearchitektur entsteht durch UML Codegenerierung Rhapsody Software-Architekten

10 1 MILLION UML Codegenerierung Rhapsody Software-Architekten

11 Einige Missverständnisse in Bezug auf MDSD Das Modell IST die Anforderung Ein teurer Irrtum, insbesondere für sicherheitskritische Systeme Es gibt per Definitionem einen Unterschied zwischen einer Anforderung (der Problembeschreibung) und einem System (der Lösung) Die grafische Darstellung macht die Software übersichtlicher/einfacher Man kann mit Grafik leicht unübersichtlichere Software bekommen als mit Code Low-level Programmierung (Coding) ist nicht mehr nötig Das Verhalten einer Klasse muss definiert werden, z.b. durch Verwendung einer Action Language Eine Grafik zu erstellen ist nicht automatisch high-level, siehe z.b. die Verwendung von SCADE Softwareentwickler werden nur noch für die Erstellung von CG benötigt Es gibt sehr viele softwarespezifische Probleme zu lösen, insbesondere im Bereich eingebettete und Echtzeitsysteme Ein Informatiker ist darauf spezialisiert, Architekturen zu entwerfen, Abstrakt zu denken, sich an Prozesse zu halten, quantitativ, logisch zu arbeiten und exakt zu sein (die Software muss laufen, die Systemrequirements nicht). D.h. das jeder, der (formale) Modelle erstellt, Kenntnisse eines Softwareentwicklers haben muss. MDSD ermöglicht die Durchgängigkeit zwischen System und Software Das hättet ihr wohl gerne, ihr Softwaremanager und Toolhersteller Die Software IST ein System, das Modell ist eine Abstraktion dieses Systems (der Lösung). In der Realität steuert der Executable Object Code ein Gerät.

12 Was nützt modellbasierte Entwicklung im Gesamtkontext? FE MIN FE NO FE ERRORS RAISED USER REQUIREMENTS SYSTEM REQUIREMENTS DOCUMENT TRACEABILITY HARDWARE SOFTWARE FE = Funktionaler Effekt Min FE typ. Datenänderung Quelle: U York, HISE Group am Beispiel EF FCS