Modellbasierte Softwareentwicklung

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.

1. Eindeutigkeit - nur eine einzige Interpretation möglich?
2. Vollständigkeit - alle notwendigen Funktionen berücksichtigt?
3. Überprüfbarkeit - Erfüllung der Anforderungen überprüfbar?
4. Widerspruchsfreiheit - Konflikte zwischen den Anforderungen?
5. Verständlichkeit - für alle Beteiligten?
6. Herkunft - Herkunft/Begründung der Anforderung klar beschrieben?
7. Flexibilität und Abhängigkeiten - ohne Auswirkung auf andere
8. Anforderungen änderbar?
9. Rückverfolgbarkeit - eindeutig zu identifizieren?
10. Abstrahierbarkeit - Ist die Anforderung implementierungsunabhängig?
11. Klassifizierbarkeit bezüglich Bedeutung - Risiken bezüglich
12. Realisierbarkeit; Stabilität über gesamten Lebenszyklus?

Angemessenheit - Wünsche und Bedürfnisse des Benutzers abgedeckt?

Der Problemraum ist die konzeptionellen Beschreibung („was“) statt Darstellung der Realisierung („wie“)

Fachliche sicht vs. technische Konzeption:

Modelle für Problemraum:

Struktur: Klassendiagramm (Komponentendiagramm)

Verhalten: Zustands-, Kommunikations-, Aktivitätsdiagramm

Elemente der Strukturmodelle: Klasse, Objekt, Attribut, Methode, Paket, (Komponente)

Beziehungen: Generalisierung (Vererbung), Assoziation, Rolle, Aggregation, Komposition, Abhängigkeit

• Zustand
• Transition
• Start und Endzustand
• Unterzustände

Dem Zustand können drei Verhaltensspezifikationen, zum Beispiel in Form einer Aktivität oder einer Interaktion, zugeordnet werden:

• ein Verhalten, das ausgeführt wird, wenn der Zustandsautomat in den Zustand eintritt (engl. entry behaviour)
• ein Verhalten, das ausgeführt wird, wenn der Zustandsautomat den Zustand verlässt (engl. exit behaviour)
• ein Verhalten, das ausgeführt wird, während sich der Zustandsautomat im Zustand befindet (engl.doActivity)

ein Verhalten, das ausgeführt wird, wenn ein bestimmtes Event eintritt. (eng. event behaviour)

Im Gegensatz zu den ersten drei Verhalten wird beim Event Verhalten ein tatsächliches Event im Zustand angegeben. (z.B.: mouseOver / peep)

gehört zu den verhaltensdiagrammen

Entry- und exit-Aktivitäten werden in derselben Notation modelliert, benötigen aber die Schlüsselwörter entry bzw. exit anstatt der Bezeichnung des auslösenden Ereignisses, um anzugeben, dass die jeweilige Aktivität beim Betreten bzw. Verlassen des Zustands ausgeführt wird.

Ereignis kann mit Guard kombiniert werden. Die Transition feuert nur dann, wenn man im entsprechenden Zustand ist und das zugehörende Ereignis eintritt und die im Wächter spezifizierte Bedingung erfüllt ist. Bei einem impliziten Ereignis wird die Transition ausgeführt, wenn die mit dem Zustand verbundene Verarbeitung (Aktivität) beendet ist.

Unterzustände

Beispiel: Zusicherung "or"

Bei einer Bank darf ein Kunde zu einem Konto nur Privatkunde ODER Geschäftskunde sein. Mit der Zusicherun {or} in UML oder allgemein in OCL kann dies sichergestellt werden

siehe Bild

siehe Bild

Das reibungslose Zusammenspiel der Programmmodule wird durch einen „Vertrag“ erreicht, der beispielsweise bei der Verwendung einer Methode einzuhalten ist. Dieser besteht aus

• Vorbedingungen (englisch precondition), also den Zusicherungen, die der Aufrufer einzuhalten hat
• Nachbedingungen (englisch postcondition), also den Zusicherungen, die der Aufgerufene einhalten wird, sowie den
• Invarianten (englisch class invariants), quasi dem Gesundheitszustand einer Klasse.

Der Vertrag kann sich auf die gesamte verfügbare Information beziehen, also auf Variablen- und Parameter-Inhalte ebenso wie auf Objektzustände des betroffenen Objekts oder anderer zugreifbarer Objekte. Sofern sich der Aufrufende an Vorbedingungen und Invarianten hält, können keine Fehler auftreten und die Methode liefert garantiert keine unerwarteten Ergebnisse.

--> OCL ermöglicht genau diese Definition von vor-und nachbedingungen sowie invarianten

Imperative Programmierung ist ein Programmierparadigma. Danach werden Programme so entwickelt, dass „ein Programm (Anm.: der Quellcode) aus einer Folge vonAnweisungen besteht, die vorgeben, in welcher Reihenfolge was vom Computer getan werden soll “

OCL dagegen schränkt Modellelemente ein. kann z.B. bei Aktivitätsdiagrammen oder anderen benutzt werden. 

Ein OCL-Constraint besteht aus einem Kopf und einem Rumpf. Der Kopf besteht aus einem Kontext, meist eine Klasse, optionaler Variablendeklaration, einem Namen und einem Typ. Der Rumpf ist ein boolscher Ausdruck. (OCLExpression)

Pre- und Postconditions sind Constraints, die die Anwendbarkeit und die Auswirkung von Operationen spezifizieren, ohne dass dafür ein Algorithmus oder eine Implementation angegeben wird. Eine Vor-/Nachbedingung wird verwendet um eine Zusicherung welche vor bzw. nach einem Aufruf einer Operation gelten muss zu formulieren

• Bedingung, Integritätsregel
• Wertemenge eines Attributs
• Vor-oder Nachbedingungen
• Regeln f. strukturelle Eigenschaften, Ordnungen und zeitliche reihenfolge

Die SysML ist eine standardisierte Erweiterung der UML. Die Systems Modelling Language ist eine Sprache zur Modell-basierten Spezifikation von Systemen und seit 2006 auch ein offizieller Standard der Object Management Group. SysML basiert auf UML2. Modellierer, die bereits mit den Sprachkonzepten von UML und im Umgang mit UML-Werkzeugen vertraut sind, können dadurch in relativ kurzer Zeit auch SysML erlernen und anwenden SysML benutzt nur eine Untermenge des Sprachumfangs von UML2 und erweitert diese Untermenge noch um eigene Modellelemente und Diagrammarten, die in dieser Form nicht Teil der UML2 sind. An dieser Stelle geht die SysML-Definition über den reinen Profilmechanismus hinaus, der es - zumindest in der aktuellen Version - noch nicht vorsieht, Teile des Metamodells auszublenden bzw. neue Diagrammarten zu definieren. SysML ist als Profil der UML bereits eine domänenspezifische Modellierungssprache für die Domäne der Systemmodellierung bzw. Systemtechnik. Darüber hinaus übernimmt die SysML explizit den Profilmechanismus der UML und ermöglicht damit weitere domänenspezifische Erweiterungen und Anpassung der Sprache zur Modellierung von speziellen Systemen.

SysML wurde von Experten verschiedener Industrieunternehmen deshalb entwickelt, da sich UML2 nur begrenzt eignet, um in der Systemtechnik eingesetzt zu werden und beliebige Systeme zu modellieren. Dies liegt daran, dass UML ihre Ursprünge in der Modellierung von objektorientierter Software hat und daher spezielle Elemente besitzt, die auf diesen Zweck hin ausgerichtet sind. Beispiele dafür sind das Klassen- und Objektdiagramm, welche genau auf die objektorientierte Softwaremodellierung zugeschnitten sind. SysML ist als UML-Profil definiert und basiert somit auf der UML2. Dies hat den Vorteil, dass zum einen kein komplett neues Metamodell für die Sprachdefinition erstellt werden muss, und zum anderen Diagramme der UML2 modifiziert oder unverändert in die SysML übernommen werden können.

Erweiterungen gegenüber der UML:

• Blöcke
• Flüsse
• Eigenschaften von Werten
• Zuordnungen – allocations
• Anforderungen
• Parametrisierung
• Kontinuierliche Abläufe: Signale, Medien, Ströme

Anforderungsdiagramm. Mit dem Anforderungsdiagramm (engl. requirement diagram) schließt SysML eine Lücke der UML, nämlich die fehlende Möglichkeit, Systemanforderungen explizit zu modellieren. Viele UML-Werkzeuge brachten bisher eigene Erweiterungen mit, um diese Schwäche zu kompensieren. Mit der Definition innerhalb des SysML-Standards wird nun eine einheitliche Darstellungsform für Anforderungen festgelegt und damit die Austauschbarkeit der Modelle über verschiedene Werkzeuge hinweg sichergestellt.

Alle UML Diagramme und neue:

• Anforderungsdiagramm
• Parametric Diagramm

veränderte Diagramme:

• Aktivitätsdiagramm
• Block Definition Diagram
• internal Block diagram

• über flow ports?

siehe bild

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