Modellbasierte Softwareentwicklung

M3: ist das MOF und beschreibt sich selbst

M2: ist eine Modellierungssprache der UML

M3: ist ein konkretes UML Modell

constraints können mit der OCL beschrieben werden

siehe bild

Problemraum:

• beinhaltet Zielstellung
• Spezifikation
• Fachl. Zusammenhänge
• z.b. gescäftsregel für kreditvergabe

Lösungsraum

• techn. Realsierung
• Beschreibung von interna
• Technische Zusammenhänge
• z.B. technischer aufbau eines systems

Codegenerierung ist auf basis von templates mit tags möglich.

Oft eingesetzt für Z.B. Webseitenprogrammierung u. Testfallgenerierung

Zwischen Problemmodell und Lösungsraum existiert eine semantische Lücke zwischen fachlichem Modell und technischer Realisierung. Dazu wird Konfigurationswissen benötigt wie

• defaults
• Abhängigkeiten
• ungültigeKombintionen
• Produktionsplan
• optimierungen

Modellierungs- oder Programmiersprache mit Fokus auf eine
Domäne
● Domänenvokabular
● Metamodell mit abstrakter Syntax und Constraints als Kern
● Klar definierte (dynamische) Semantik: formal oder intuitiv
● Höheres Abstraktionsniveau
● Meist vorhanden: Abbildung auf Implementierung z.B. auf
Programmiersprache
● Meist nicht Turing-vollständige Programmiersprachen, sondern
deklarativ

z.b. excel, html, matlab, sql, java...

Es gibt verschiedene Phasen für die DSL Entwicklung

1. Domänenanalyse

2. Entwicklung eines Metamodells

3. Entscheidung über Art und Technologie d. DSL (intern, extern, grafisch, textuell)

4. Definition der DSL: konkrete Syntax

5. Bereitstellung oder Entwicklung der Werkzeuge

Für die zweite Phase, Metamodell entwickeln, spielen Modell eine wichtige Rolle, um dies als basis für die weiteren Schritte zu verwenden

Interne DSL:
● mit Mitteln einer anderen (Host-)Sprache ausgedrückt, in diese
Sprache eingebettet
● Meist mit dynamisch getypten Sprachen wie Ruby und LISP
● Vergleichbar mit Bibliothek, sieht aber nicht wie Host-Sprache aus
sondern wie eigene Sprache
● Wenig Toolunterstützung möglich, für „kleine“ Anwendungen

Externe DSL:
● Unabhängig von anderen Sprachen erstellt
● eigener Parser

Informationen grafisch

● Gut für Kommunikation:
● Diskussionsgrundlage
● Strukturen verstehen
● Informationsmenge begrenzt
● Werkzeugunterstützung für
Veranschaulichung von
Sichten, Abstraktion,
Hierarchisierung notwendig

Informationen als Text

● Einfach durch Werkzeuge
unterstützbar
● Gemeinsame Bearbeitung
im Team
● Versionierung
● Werkzeugunterstützung für
Visualisierung notwendig
● Code Folding
● Outline View

keine ahnung???

Ziele und nutzen:

Zielerreichung sichern:
Anforderungserfüllung des
Projektes prüfen
● Alle Ziele und Anforderungen
nach jedem
Entwicklungsschritt prüfen
Qualität verbessern: Anzahl von
Fehlern und Mängeln verringern
● Menschen: 3% Fehler,
Werkzeuge: systematisch
● Menschen: begrenzte Mengen
an Informationen verarbeitbar,
Werkzeuge können mehr
Fehlerbehebungskosten verringern
● Fehler und Mängel frühzeitig
finden
Entscheidungsfindung verbessern
● Systemeigenschaften bei
Entwurfsentscheidung
vorhersagen
● Lösungen bezüglich der Ziele
optimieren

Struktur: Bestandteile, Gliederung, Beziehungen,
Zuordnung
● Funktionalität: (Semantische) Korrektheit, Vollständigkeit,
Interoperabilität
● Verhalten: Zustandsverhalten, Zeitverhalten,
Nebenläufigkeit
● Effizienz: Lastverhalten, Skalierbarkeit,
Ressourcenbedarf
● Sicherheits-Eigenschaften: Vertraulichkeit, Integrität,
Verfügbarkeit
● Zuverlässigkeit, Robustheit ... und viele mehr

Aufwand für formale Modellierung
der Ziele und Anforderungen

● Modellierungssprache
entwickeln
● Wissenserwerb und
Einarbeitung
● Formalisierung der Ziele und
Anforderungen
Aufwand für Werkzeuge
● Kosten des Werkzeugs
● Wissenserwerb und
Einarbeitung
● Aufwand für Bedienung

Nutzen
Vermiedene Schäden durch Fehler
und Mängel
● Reklamation
● Verlust an Reputation
Schwierigere Projekte möglich
● Mehr Gewinn weil besser
bezahlt
● Interessantere Arbeit, lukrativ
für Mitarbeiter
Formale Zulassung erreichbar
● Z.B. Luft- und Raumfahrt

• siehe bild

Ziel Security: • InformaRons--‐/Datenflüsse prüfen • Ursache--‐Wirkung von Angriffen prüfen • Abhängigkeiten zwischen Komponenten prüfen

• Integrationsrahmen eines iterativ, inkrementellen Projekts
• Grundlage der Projektplanung und Management: Organisation, aktive Führung, Einblick, Verhandlungsbasis
• unabhängige, verteilte Implementierung

Qualitätsmerkmale nach ISO 25020, 25022

• Wartbarkeit
• Übertragbarkeit
• und Zeitverhalten, Robustheit Sicherheit

Ziele

• Effizientere Entwicklung
• Risiken minimieren
• verständnis schaffen
• Kernwissen des Systems konservieren

• Funktionalität
• Benutzbarkeit
• Zuverlässigkeit
• Effizienz

• hoher Formalisierungsgrad
• Detailgrad
• Einfachheit, Übersicht wegen der hohen Komplexität
  • Abstraktion
• Bewertung (Validierung & Verifikation)
  • max. notwendige Details
• Redundanz
• Beherrschbarkeit der Komplexität
• Verstehen von Zusammenhägen durch verbinden von Sichten

beschränktes Abbild der Wirklichkeit mit drei Hauptmerkmalen:

• Abbildungsmerkmal
• Verkürzungsmerkmal
• Pragmatisches Merkmal

Schächen:

• semantische Lücke zwischen Anforderungen und Entwurf
• Objekt/Nachricht Metapher gilt nur für kleine Elemente
• versteckt wesentliche Elemente Steuer und Datenfluss
• Starke Abhängigkeit zwischen den Elementen

Stärken

• Objekte zur Modularisierung
• Abstraktion im Problemraum
• Abstraktionsebene (Vererbung)
• Logische Gliederung
• Nachrichtenaustausch als Metapher

• Optimierung von Prozessen
• Öffnung von Systemen für das Web
• Kopplung mit externen Systemen:  Für viele Dinge gibt es schon Systeme, aber manchmal müssen die Daten gekoppelt werden. Dadurch muss es Schnittstellen geben
• Organisationsänderung Wenn sich ein Unternehmen ändert muss auch die Software geändert werden. Bsp: Eine Firma kauft eine Andere und die Lagerhaltung soll zusammengelegt werden.
• Änderung gesetzlicher Grundlagen Z.B Steuerrecht ändert sich jährlich. Maschinenbauer haben bei schlechter Konjunktur mehr Probleme als Informatiker. Für eine Bank ändern sich die gesetzlichen Bedingungen immer
• Änderung der technischen Plattform Neue Version einer Datenbank (Oracle 6 und 7)
• Fehlerbehebung
• technischer Fortschritt

• Komplexität
  • Workflows, Hardwareersetzung, heterogene Systeme
• Agilität und Veränderungen
  • Prozessoptimierung, Organisationsveränderungen, gesetzliche Grundlagen..
• Langlebigkeit
  • hohe investitionen, ungern veränderte Workflows
• Kosten und Aufwandsreduzierungen

• Schritte des Produktionsprozesses
• maximale Zeitdauer
• Abhängigkeiten um eventuelle Warteschlangen mit zu modellieren
• Kapazitäten

• Akteur
• Assoziation
• Systemname
• Systemgrenze
• Extend und Includesbeziehung
• Use-Case

• Anwendungsfall-Nr. Name des Anwendungsfalls
• Akteure
• Vor- und Nachbedingungen
• Invarianten
• Qualitätsmerkmale
• Ablaufbeschreibung / Durchführung
• Ausnahmen, Fehlersituation
• Alternativabläufe

• Abstraktion
• Wiederverwendung
• Generalisierung/Vererbung
• Hierarchisierung
• Modell "zerschneiden" um Überblichk zu bewahren

Beispiel Termin erfassen:

Das Use-case Diagramm enthält use cases. Diese use-cases können feiner beschrieben werden in der Use-caseBeschreibung oder anhand eines Aktivitätsdiagrammes.

im Use case diagramm sind lediglich die Systeme und use cases und interaktionen aus sicht des Akteurs vorhanden. Bei einem Aktivitätsdiagramm ist eine detallierte Beschreibung des Ablaufs der Fokus.