Quo vadis, Modellierung? Prof. Dr. Holger Giese Fachgebiet Systemanalyse und Modellierung

Transkript

1 Quo vadis, Modellierung? Prof. Dr. Holger Giese Fachgebiet Systemanalyse und Modellierung

2 Übersicht 2 I. Was ist Modellierung? II. Modellierung in der Informatik III. Aktuelle Herausforderungen IV. Die Zukunft der Modellierung V. Ausblick & Arbeiten am Fachgebiet

3 I. Was ist Modellierung? 3 Herbert Stachowiak; Allgemeine Modelltheorie, Springer-Verlag, Wien Modelle sind im Allgemeinen abstrakte Abbilder oder Vorbilder zu konkreten oder abstrakten Originalen. Abbildung eines Originals: es gibt immer einen Bezugspunkt Eine Funktion a die dem Original O ein Modell M zuordnet (Abstraktion). Eine nicht eindeutige Rückabbildung i die einem Modell M ein Original O zuordnet (Interpretation). Reduktion: nicht alle Eigenschaften werden wiedergegeben Pragmatik: Modell kann das Original für einen Zweck ersetzten Original a Modell weggelassene Eigenschaften O M überflüssige Eigenschaften

4 Beispiel: Karte der Londoner U-Bahn 4 Abbildung: Bezug zur echten U-Bahn London a Reduktion: Weggelassene Eigenschaften: Korrekte geometrische Distanzen/Lage Höheninformationen, Straßen, Überflüssige Eigenschaften: Geometrische Distanzen/Lage sind nicht korrekt Karte der U-Bahn von London Pragmatik: Navigation in der U-Bahn (aber nicht darüber hinaus!)

5 Validierung, Verifikation & Analyse 5 Umgebung Original Validierung: Beschreibt das Modell das Original für den Zweck korrekt? a a Modell Modell Verifikation: Ist das Modell bezogen auf andere Modelle korrekt? Analyse: Welche Eigenschaften erfüllt das Modell? Durch den Zweck des Modells beschränkt!

6 Modelle in den Naturwissenschaften 6 Vergleich durch Experiment führt zur Validierung des Modells (und ggf. der dahinterstehenden Theorien) Original Modell abstrahiert (deskriptiv) Konstruktion: Modell wird in der Regel auf Basis anerkannter wissenschaftlicher Theorien hergeleitet Nutzen: Ein valides Modell ermöglicht Vorhersagen für ein System Validität des Modells bestätigt Theorie Analyse ermöglicht Vorhersagen

7 Modelle bei den Ingenieuren 7 Konstruktion fiktives Original Modell Original abstrahiert (präskriptiv) Modelle realisiert? Systemanforderungen abstrahiert (deskriptiv) Analysen bestätigen die Erfüllung der Anforderungen Konstruktion: Modell wird auf Basis der Systemanforderungen und anerkannter wissenschaftlicher Theorien hergeleitet Nutzen: Erfüllung der Anforderungen kann kostengünstiger am Modell gezeigt werden, da Analyse am Modell einfacher ist und Original oft erst später analysiert werden kann.

8 II. Modellierung in der Informatik 8 Heute: Softwaresystem Beobachtungen: Original und Modelle sind immateriell realisiert? Compiler abstrahiert (präskriptiv) abstrahiert (präskriptiv) abstrahiert (deskriptiv) Entwurfsmodell Implementierung (Modell) Analyse bzgl. Eignung und Entwurfsmodell Analysemodell Systemanforderungen Analyse bzgl. Eignung und Analysemodell Analyse bestätigt Erfüllung der Anforderungen Programmierung Modellierung

9 Wieso nicht nur Programmierung? 9 Compiler Systemanforderungen Implementierung (Modell) abstrahiert (präskriptiv) realisiert? abstrahiert (deskriptiv) Analyse bzgl. Eignung und Erfüllung der Anforderungen Beobachtungen: Nach der allgemeinen Definition findet immer Modellierung statt! Ein einziger Schritt ist aber häufig zu schwierig (hohe Komplexität), da Konsensbildung immer nötig und Arbeitsteilung häufig nötig Compiler Softwaresystem Entwurfsmodell Implementierung (Modell) abstrahiert (präskriptiv) Analyse bzgl. Eignung und Entwurfsmodell realisiert? abstrahiert (präskriptiv) Systemanforderungen Analysemodell Analyse bzgl. Eignung und Analysemodell Softwaresystem abstrahiert (deskriptiv) Analyse bestätigt Erfüllung der Anforderungen Konsequenzen: Programmierung reicht nicht! Zusätzliches Analysemodell: Zuerst verstehen was der Kunde wirklich will (Konsensbildung)! Zusätzliches Entwurfsmodell: Detaillierte Lösung als Grundlage für die Arbeitsteilung zuerst auf höherer Abstraktionsebene planen!

10 Konsensbildung & Arbeitsteilung 10 Implementierung Implementierung Analysemodell Entwurfsmodell Implementierung Implementierung Was? Wie grob? Wie detailliert?

11 III. Aktuelle Herausforderungen 11 (1) Ständige Evolution statt Revolution (2) Agilität statt Vorhersagbarkeit (3) Exponentiell wachsende Komplexität Bemerkung: Je nach Anwendungsdomäne sind die Herausforderungen aber verschieden relevant!

12 (1) Ständige Evolution statt Revolution 12 Beobachtung: Softwaresysteme werden oft unersetzlich Erklärung: Software beinhaltet oft Wissen der Organisation Beobachtung: Programme altern, obwohl sie digital sind. Erklärung: Lehman s Laws of Software Evolution 1: Ständige Anpassung an Umgebung, sonst nutzlos (Evolution der Umgebung) 2: Ständig steigende Komplexität, wenn nicht gegengesteuert wird (Patches) 6: Ständige Erweiterung der Funktionalität wird für Kundenzufriedenheit benötigt Wartung 40-80% Implemen tierung Entwurfs Analyse Implemen tierung Entwurfs Analyse

13 (2) Agilität statt Vorhersagbarkeit 13 Fragestellungen: --Wie Wie gut gut versteht der der Kunde Kunde seine seine wirklichen Bedürfnisse? --Wie Wie schnell schnell ändert ändert sich sich der der Markt Markt für für die die Software? Wieviel WievielAufwand lohnt lohnt sich sich bei bei den den frühen frühen Entscheidungen?

14 (3) Exponentiell wachsende Komplexität 14 Hintergrund: Moore s Law: Leistungsfähigkeit der Hardware verdoppelt sich (bisher) alle 18 Monate. Nathan s 2. Law: Software wächst bis sie durch Moore s Law begrenzt wird. Nathan s 4. Law: Bedarf nach Software ist nur durch menschliche Zielsetzung/Erwartungen begrenzt. Möglichkeiten werden immer voll ausgeschöpft werden! The Moore s Law of Platform Complexity: Platform complexity doubles every few years. Languages and Paradigms hardly keep up. Complexity hard-wired assembly Platforms 3GLs, 4GLs OO (+OOA/OOD) Languages, Paradigms 50 s 60 s 70 s 80 s 90 s 2000 s Dr. Axel Uhl, Chief Development Architect, SAP, Office of the CTO

15 Herausforderungen und Modellierung? 15 Ständige Evolution statt Revolution Problem: Es gibt nur Programme und keine Modelle? Problem: Konsistenz der Modelle und des Programms? Agilität statt Vorhersagbarkeit? Problem: Frühes Feedback für Anforderungen wichtig! Problem: Zusätzliche Änderung der Modelle notwendig! Exponentiell wachsende Komplexität Problem: Steigerung der Produktivität? Resultierende Frage: Fahren wir in in Zukunft besser mit mehr oder weniger Modellieren als heute?

16 IV. Die Zukunft der Modellierung? 16 Bisherige Entwicklung: ~1950 Assembler 1977 SADT 1957 Fortran, 1967 Simula, Smalltalk 1983 Tuxedo App. Server Informationsgehalt Analyse Entwurf Implementierung Plattformen Objektorientierung Wiederverwendung Hochsprache Kosten umsonst Assembler Frage: Setzt sich dieser Trend fort? Detaillierungsgrad

17 (1) Model-Driven Architecture (MDA) 17 Ein Ansatz zur Spezifikation von IT Systemen, der die Spezifikation der Systemfunktionalität betreibt ohne jedoch sich bereits auf eine gewisse Technologieplattform festzulegen. Computation Independent Model (CIM) Plattformunabhängige Modelle (PIM) Plattformabhängige Modelle (PSM) UML, UML, Plattformen (e.g., EJB Profile, ) Design once, build it it on on any platform Codemodell (+ Plattform, ) Java, (+ EJB, )

18 18 Zukünftig Entwicklung: Ansatz der MDA Code-Generierung Kosten umsonst Modelltransformationen Analyse Entwurf* Entwurf Implementierung* Informationsgehalt Implementierung Plattformen Objektorientierung Hochsprache Assembler Wiederverwendung Detaillierungsgrad

19 (2) Domänenspezifische Sprachen (DSL) 19 (Lösung des Problems in Termini der Domäne) komplexe Abbildung ist nötig Abbildung ist nötig UML Modell Code häufig nur partiell Domainmodell Softwareprodukt keine Abbildung nötig Domänenmodell

20 20 Zukünftig Entwicklung: Ansatz für DSLs Code-Generierung Kosten umsonst Informationsgehalt Entwurf Implementierung Plattformen Objektorientierung Hochsprache Assembler Wiederverwendung Analyse Detaillierungsgrad

21 Luft- und Raumfahrt: Beispiel SCADE (1/2) 21 Werkzeug: Safety Critical Applications Development Environment (SCADE) Anwendung: A340/600 FCSC (Flight Control Secondary Computer): Source: Esterel Technologies Ergebnis: 70% automatisch generierter Code 50% Einsparung bei den Entwicklungskosten Verkürzung der Änderungszeit um den Faktor 3

22 Luft- und Raumfahrt: Beispiel SCADE (2/2) 22 Manuelle Programmierung Automatische Codegeneratoren Qualifizierte Codegeneratoren Verifikation auf Basis der Modelle Keine Modultests (bzw. automatisiert) Zeit [Camus&Dion2003]

23 Luft- und Raumfahrt: Einsparungspotential 23 Hans-Peter Erl & Sascha Kirstan. Studie "Kosten-/Nutzenanalyse der Modellbasierten Softwareentwicklung im Automobil" Arthur D Litte/TU Munich, München, Januar 2007.

24 Diskussion der Ansätze 24 Frage Ständige Evolution statt RevolutionMDA DSLs MDA+DSLs Anwendbarkeit Problem: Es gibt nur Programme komplexe und keine einfache Modelle? komplex Problem: Konsistenz der Projekte Modelle und Projekte des Programms? Projekte Aufwand Agilität statt (Infrastruktur) Vorhersagbarkeit? niedrig sehr hoch mittel Aufwand (Analysetechniken) mittel sehr hoch hoch Problem: Frühes Feedback für Anforderungen wichtig! Aufwand (Projekt) mittel sehr niedrig niedrig Problem: Zusätzliche Änderung der Modelle notwendig! Keine Modelle Rückwärts? Rückwärts? Rückwärts? Exponentiell wachsende Komplexität Konsistenz/ Vorwärts Vorwärts Vorwärts Problem: Steigerung der Produktivität? Zusätzliche Änderung Rückwärts? (Rückwärts) Rückwärts? Frühes Fragen: Feedback? - Welche Aufwand verursachen? (Ausführung) die Ansätze? (Ausführung) Steigerung - Werden der Produktivität die Herausforderungen + adressiert?

25 V. Ausblick & Arbeiten am Fachgebiet 25 Wesentliche offene Punkte: Frühes Feedback? Keine Modelle? Konsistenz/zusätzliche Änderung Infrastrukturkosten? Kosten für Analysentechniken? Prognosen: Für einige Domänen werden sich entsprechende DSLs durchsetzen (Dominanz): Luft- und Raumfahrt: Eingebettete Systeme (und speziell Automotive Systeme): wird kommen! Business IT: Geschäftsprozessnotationen werden vermehrt als DSLs fungieren Für komplexe, allgemeine IT-Systeme wird es beides geben (Koexistenz): Auf Architekturebene Modelle (wahrscheinlich UML) Innerhalb der Architekturkomponenten Programmiersprachen oder DSLs Zukunftsvision: Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen. (Winston Churchill u.a.) Software, die sich mit Hilfe von Modellen teilweise selbst funktionstüchtig erhält (autonomic computing, Selbst-X).

26 Arbeiten am Fachgebiet Die beste Art, die Zukunft vorauszusagen, ist, die Zukunft zu erfinden (Alan Kay) 26 Wesentliche offene Punkte: Prototyping mit Modellen Frühes Feedback? Keine Modelle? Modellsynchronisation Konsistenz/zusätzliche Änderung (vorwärts, rückwärts) Infrastrukturkosten? Modellkonsistenz Kosten für Analysentechniken? Modelle, SOA & Selbst-X Modellanalysen (Agilität & Evolution zur Laufzeit) N.N. Stephan Hildebrandt Andreas Seibel Thomas Vogel Basil Becker Stefan Neumann Fr. Miers

27 Fragen? Prof. Dr. Holger Giese Fachgebiet Systemanalyse und Modellierung