Im letzten Abschnitt dieses Kapitels möchte ich mit Ihnen diskutieren,
wie weit wir Modellierung treiben wollen,
wie weit ist das Treiben solcher Modellierungen sinnvoll ist.
Der Abschnitt 4,5 diskutiert deswegen, wie weit wir formalisieren,
wie weit wir Werkzeug unterstützen wollen.
Dazu gehört die Frage 11, die uns fragt,
wie weit formale Spezifikationen positiv oder negativ sich auswirken und was
für Eigenschaften sie hat.
Dabei werden wir, darauf werden wir eingehen.
Zunächst brauchen wir erstmal ganz zum Schluss eine neue Seite und
das ist der Abschnitt
Ich schreibe die Überschrift nochmal hin, ausführbare Spezifikationen.
Gegenüber versus Grafiken. Man könnte dabei auch fragen,
mehr Modellierung oder weniger Modellierung
Ja, dieses Spannungsfeld, diese Entscheidung möchte ich
kurz mal hier bei dem Beispiel von Anforderungen darstellen.
Wir werden bei der Implementierung auch noch gelegentlich drauf kommen.
Und zum Schluss haben wir sogar den Abschnitt Domain spezifische Sprachen,
wo es um komplett ausführbare Modelle geht.
Lassen wir uns anfangen mit ausführbaren Spezifikationen, dass die Seite
mehr Modellierung. Zunächst möchte ich gerne mit Ihnen überlegen,
was für Voraussetzungen dafür
notwendig sind
Die Voraussetzungen sind natürlich zunächst erst mal, wenn ich etwas ausführen will,
muss ich in irgendeiner Form ein Softwarewerkzeug dafür haben.
Ja, also das ist erst mal,
das könnte ein Modellinterpreter sein oder irgend so etwas.
Oder etwas Ähnliches. Das ist eine wichtige Voraussetzung.
Die nächste wichtige Voraussetzung, wenn wir etwas ausführen wollen,
dann können wir uns uns nicht leisten,
wie wir das beim Modell gesagt haben oder der Modelldefinition.
Wir nehmen nur das rein,
was uns interessiert
Wenn ich es ausführen möchte, muss ich komplett alle Elemente
dargestellt haben, jeden Sonderfall. Jeder Bezug, jedes Datenelement,
alles muss in diesem ausführbaren Modell, einer Spezifikation enthalten sein.
Also wir können nicht das weglassen, was wir sagen,
ist ja selbstverständlich oder es uns zu detailliert, machen wir später.
Dann brauchen wir eine sehr weitgehende Detailreihe, sehr weitgehend detailreich tun.
Also wir brauchen ein sehr präzises Modell, Alle Details müssen enthalten sein.
Was ich vielleicht noch sagen müsste, bei der Vollständigkeit,
es muss auf jeden Fall formal definierte Syntax und Semantik haben,
weil sonst ja nicht von einem Tool verstanden werden kann,
also irgendwie freier Text,
der Mensch wird es schon verstehen,
das hilft für ein Tool nicht
Der formal definierte Syntax und Semantik, also das, was eine Programmiersprache auch hat.
Klar, die Bezeichner sind ganz interessant zu verstärken und versteht,
was das tut, aber eigentlich muss es der Compiler verstehen.
Und hier müsste es sowas wie ein Modellinterpreter eben verstehen können. Soweit erstmal,
das müssen wir alles haben, damit wir ein ausführbares Modell erreichen können,
aber wir brauchen noch mehr, nämlich wir müssen es auch noch anpassen an Besonderheiten.
Also ich gehe mal zurück zu dem System, zu dem Systemkontext,
wo wir die Darstellung hatten, was denn da alles dazugehört,
wenn wir jetzt mit verschiedenen, zum Beispiel,
sie wollen eine App unter Antroid und eine App-App unter iOS für die Apple-Fans bereitstellen,
die jeweils ein bisschen unterschiedliche Schnittstellen haben,
dann müssen sie beide Versionen an der Schnittstelle vorsehen.
Wenn sie Aktuatoren von verschiedenen Herstellern anbilden wollen, die netten Lämpchen,
Philipp Sue oder von anderen Herstellern halt auch noch,
dann müssen sie, wenn sie die unterstützen wollen,
müssen sie für jeden, für jedes Ding eine Variante haben.
Und diese Varianten müssen wir überschaltert dann entsprechend,
wenn ich hier nur sage, hier liegt an,
dann muss ich noch sagen,
liegt an für den Hersteller,
liegt an für den Hersteller
Ich muss die ganzen,
das muss ich am Ende über Parameter steuern,
was am Ende wir für Vielfalt hier haben wollen.
Das brauchen wir also auch noch als Voraussetzung.
Also die Anpassung an Umgebung über Parameter.
Bei der Umgebung ist auch die technische Plattform gemeint
So, das ist die, das ist erstmal das,
was wir hier brauchen und was können wir damit erreichen?
Wenn wir ein ausführbarer Spezifikation haben, können wir natürlich zunächst erst mal alle das,
alles das machen, was wir dem Nutzer zeigen können.
Also das ist schon mal super hilfreich. Wir hatten ja ganz zu Anfang darüber gesprochen,
wie schwer es ist zu verstehen,
was der Benutzer eigentlich möchte und der Benutzer muss der Kunde,
muss erst mal seine Ideen entwickeln und das kann er natürlich sehr gut,
indem wir ihm zeigen, wie das dann funktioniert.
Also was wir auch, was wir, also Was wir
also dort erreichen können, wäre, dass wir einen Prototypen bereitstellen.
Ja, der Prototyp, der hilft uns zum Beispiel eben beim Veranschaulichen.
Oder auch, um etwas auszuprobieren. Überprüfen, ob etwas funktioniert.
Ja, das wäre eine wichtige Funktion. Wir haben,
indem wir das modelliert haben und das Modell ausführen können,
können wir das prototypisch bereitstellen. Und vielleicht nicht funktioniert nicht
alles, aber wir können schon einen Eindruck gewinnen.
Was auch noch mit einem ausführbaren Modell möglich wäre,
ist, dass wir bestimmte Sachen simulieren.
Simulation hat auch etwas Unvollständiges im Wortschuhen. Ja,
wir machen es nicht wirklich, sondern wir simulieren es nur.
Das ist also auch kein Modell, was alles durchführt,
was am Ende das System können soll. Prototyp tut auch nicht alles,
aber jede Simulation wäre immerhin dafür möglich, dass wir,
dass zum Beispiel das Zusammenspiel von Teilen prüfen können,
neben den Sachen,
die der Prototyp kann
Das, was ich hier in Klammern schreibe,
ist natürlich immer nur ein Beispiel, um Ihnen zu sagen,
was könnte ich denn damit tun?
Als weitere Möglichkeit wäre, dass ich etwas validieren kann.
Validieren, valide, etwas gültig kann ich prüfen,
ob das Ganze korrekt ist, ob es gültig ist.
Das wäre zum Beispiel möglich,
indem ich Testfälle bereitstelle
Indem dieses Werkzeug oder das Modell für diesen Kontext dann sozusagen den Spiegel darstellt,
die Testumgebung bereitstellt, mit der ich dann prüfen kann,
ob das Werkzeug, ob mein System das richtige Verhalten hat.
Aber wir können auch das komplett generieren, ein komplett ein ausführbares System.
Auf Basis der Spezifikation Das heißt, die Spezifikerspezifikation,
das können wir noch mal ein bisschen besser machen hier.
Die Spezifikation ist also, dass die, die ist das System.
Ja, die Spezifikation, indem ich die Spezifikation beschreibe,
beschreibe ich das System und ich programmiere nichts weiter,
sondern das System wird daraufhin ausgeführt. Das sind natürlich enorme Vorteile,
wenn ich das alles machen kann, aber jetzt denken Sie mal daran,
was wir jetzt hier für alles brauchen,
wenn wir das komplett ausführen, müssen wir wirklich jedes Detail der Ausführung,
sind, wie sind die Felder angeordnet im grafischen Nutzer,
in der grafischen Nutzerschnittstelle?
Wie sind die Grenzbereiche für Parameter bei Gültigkeitsprüfungen?
Was passiert im Fehlerfall? All das muss dargestellt werden und
das muss alles jeweils für jede Variante der Umgebung,
soweit sie unterstützt wird, dargestellt werden.
Sie können sich vorstellen, dass ein solches Werkzeug,
was das alles kann, extrem mächtig ist. Und der Aufwand,
den wir braucht, um so ein Werkzeug zu bauen,
der es um ein Vielfaches höher als der Werk,
also den Aufwand, den ich brauche, um ein System zu entwickeln.
Das lohnt sich also nur unter ganz bestimmten Bedingungen,
nämlich dann, ich ganz viel nutzen aus diesem Generator habe.
Und bitteschön, diesen Nutzen möchte ich haben noch,
bevor es sich alles ändert.
Wenn wir nämlich dann plötzlich zwischendurch eine neue Version der Programmiersprache
unterstützen müssen oder ein ganz anderes Schnittstellen oder neue Standards,
dann können wir dieses Werkzeug, diesen Generator, diesen Interpreter,
der die Spezifikation dann ausführt, eigentlich nochmal neu entwickeln.
Das heißt, das Ganze funktioniert auch nur,
gerade hier das Letzte, solange sich nichts Grundlegendes ändert.
Und wir wissen ja, die Veränderung ist das Konstante
Wir schauen mal zurück auf die Frage, die wir hier hatten dazu.
Das war die letzte Frage in unserer Reihe. Vorteile und Nachteile
formaler Spezifikationen, Beantwortungsbeschreibungen, anhand der Kriterien der Prüfung,
der Risiken des Projekts und der Effizienz des Entwicklungsprozesses.
Da machen wir uns eine kleine Tabelle, um das beantworten zu können.
So, die Kriterien, ich muss da nochmal zurückschalten,
dass ich mir das Es geht um formale Spezifikationen bei Anforderungsbeschreibungen.
Also das, was wir brauchen, wenn wir Modelle ausführbar
machen wollen im Sinne von formal definierter Syntax und Semantik,
das ist mit formaler Spezifikation gemeint.
Und wir brauchen jetzt Kriterien für die Prüfung
Die Kriterien für die Prüfung hatten wir schon mal,
das waren die Abnahmekriterien, ich springe mal dahin zurück.
Das waren, auf dieser Folie, diese Kriterien für die Vollständigkeit,
für die Eindeutigkeit, für die Überprüfbarkeit, Widerspruchsfreiheit, Verständlichkeit.
Also das, was wir an Eindeutigkeit, Vollständigkeit,
Überprüfbarkeit haben, das ist natürlich,
wenn wir eine vollständig formal definierte Beschreibung haben,
sehr viel besser.
Das Gleiche trifft zu auf die Widerspruchsfreiheit
Wenn wir dort sagen, einem einen ist der Wertebereich so definiert,
beim Mann ist der Wertebereich so definiert,
wenn wir es im Modell haben, würde uns das sehr stark,
können wir das auf jeden Fall finden.
Auch wenn wir in Formal definiert haben, von wem kommt denn was?
Da könnten wir auch wunderbar mit Prioritäten arbeiten.
Auch die Rückverfolgbarkeit von Anforderungen, wenn wir Zerlegung haben,
was führt er wozu? Und das alles im Modell haben
, wird das vermutlich vermutlich ganz gut gehen.
Also ein paar Sachen gehen da gut.
Das können wir hier
mit aufnehmen
Vorteilhafte sind, ist die Formalspezifikation für die Kriterien, Vollständigkeit, Widerspruchsfreiheit.
Eindeutigkeit, ich nehme die jetzt nicht alle auf,
aber es gibt auch ein paar Punkte,
wo es nicht so gut funktioniert,
wo wir Nachteile zu sehen haben.
Und zwar ist das
insbesondere hier diese Verständlichkeit für alle Beteiligten
Uns formale Spezifikationen. Sie haben theoretische Informatik,
ich glaube alle, aus allen Studiengängen sind sie,
beschäftigen sich damit, ja, so eine Logik,
so ein Logikkalkül oder wenn wir Abläufe mit Petrinetzen beschreiben oder
gar mit einer algripparischen Spezifikation, das versteht nicht jeder.
Das heißt, die Verständlichkeit ist gering. Das Gleiche trifft zu, Flexibilität.
Wir können nur das darstellen, was in unserer Sprache,
in unserer Semantik und Syntax denn vorgesehen ist.
Mal schnell was ergänzen, das,
was ein Programmierer natürlich selbstverständlich kann,
das könnten wir nicht
Und auch das, ja, bleiben wir mal dabei.
Angemessenheit könnte man da auch noch diskutieren,
aber ich denke, diese beiden Sachen reichen Verständlichkeit und Flexibilität.
Also, die formale Spezifikation ist vorteilhaft für Diese Prüfkriterien,
Vollständigkeit, Widerspruchsfreiheit, Eindeutigkeit und nachteilig bei den Prüfkriterien,
Verständlichkeit, Abnahmekriterien.
Ich schreibe da mal vielleicht Prüfung. Und Abnahme.
Abnahme. Eine Spezifikation. Ach, ich glaube,
das heißt Anforderungsbeschreibung bei uns. Schauen wir doch schnell mal
, dann schreiben wir hier
auch Anforderungsbeschreibung
Ja, für die Einforderungsbeschreibenden ändern wir das hier auch,
damit das für Sie auch beim Nachlesen später mal noch gut passt.
Also hier ein Anforderungsbeschreibung. So, das war die Wirkung,
Auswirkungen auf Anforderungs-, auf die Prüfkriterien,
auf die Abnehmerkriterien und wir sollen ja noch weiter sagen,
wie sieht das für die Risiken eines Projektes aus
Risiken eines Projektes sind, dass das Projekt fehlschlägt.
Das Projekt könnte fehlschlagen, weil es seine Ziele nicht erfüllt.
Das Projekt könnte fehlschlagen, weil es zu viel Aufwand herfordert
und deswegen über das Budget geht oder über die Zeit,
die wir dafür vorgesehen ist.
All das sind Risiken, wo ein Projekt fehlschlagen kann.
Ein Projekt, dass das Projekt fehlschlägt, weil es zum Beispiel
Korrektheit nicht erreicht oder weil die in die Eigenschaften nicht erfüllt werden.
Das ist etwas weniger wahrscheinlich, wenn wir eine formale Spezifikation, eine ausführbare Spezifikation haben.
Also die Risiken werden positiv beeintwortet, sind geringere Risiken.
Bezüglich Korrektheit bezüglich Qualitätseigenschaften Wir können davon ausgehen,
wenn das System erstmal das mit diesem,
was wir von vorher hinten Bild haben, also wenn wir uns,
wenn es uns gelingt, so ein Werkzeug zu bauen,
dann wird das auch gut funktionieren.
Hoffentlich, dass das Werkzeug gut funktioniert. Doch das ist
schon ein Risiken, das ist ein Risiko für das Projekt
und das
wieder als Stift
Wir sind nämlich sehr stark davon abhängig,
dass das Werkzeug funktioniert, wegen Abhängigkeit. Von dem Werkzeug,
also ich meine wieder, ich benutze den gleichen Begriff,
Modellinterpreter, wie auch immer sie das dann konkret nennen,
was es dann wirklich ist, Modellinterpreter,
wegen der Abhängigkeiten und auch wie Grenzen der Spracher,
der Modellierungssprachen.
Denn wir haben da keine Flexibilität. Wir können nicht einfach
mal schnell diese Modellierungssprache erweitern. Ich gehe mal zurück zum vorgehenden Bild.
Also wenn wir hier das Modell vollständig beschreiben wollen mit dieser
formal definierten Syntax und Semantik, da muss das Werkzeug die auch komplett unterstützen.
Und wenn wir jetzt einfach mal hier das um neue Ausdrucksmittel
erweitern wollten, dann müssen wir auch das Werkzeug erweitern.
Und so ein Werkzeug zu testen, was ein Generator ist,
können sich vorstellen, es ist ganz schwierig, Testfälle dafür zu erstellen.
Ja, das heißt, wegen Grenzen der Modellierungssprache,
da sind größere Risiken, also wenn Flexibilität gefordert sind,
das sollten wir auch noch mit als Risiko schreiben, sehr begrenzte Flexibilität.
Von meiner Erfahrung als selben Projektleiter möchte ich sagen,
dass ganz häufig solche Werkzeuge auch Fehler haben, Unzulänglichkeiten,
wo wir dann den Herstellersupport brauchen und solche und diese Abhängigkeit
von den Werkzeugen führt dann dazu,
dass bestimmte Sachen einfach nicht gehen
Ja, und dann haben wir zwar auch was Tolles,
was das irgendwie zu 95 Prozent generiert.
Dummerweise, die fehlen 5 Prozent sind gerade das,
was so sehr stört. Das heißt, wir machen uns
sehr stark von einem solchen Werkzeug abhängig. Ja,
was wir auch noch, was die dritte Frage war,
in der Frage war, also das erste war Kriterien von Prüfungen,
Risiken eines Projektes.
Und da haben wir hier noch ein Sternchen davor,
damit wir das besser finden.
Und das letzte war Effizienz des Entwicklungsprozesses
Effizienz heißt ja, Verhältnis von Aufwand und Nutzen.
Ja, die Effizienz ist sehr hoch, wenn wir in
dem Bereich bleiben, den das Werkzeug wunderschön unterstützt.
Wer, wir wollen darüber hinausgehen. So sehr gut ist
die Effizienz, soweit von Modellierungssprache und Werkzeugen unterstützt
Und wir können das direkt rumdrehen, sehr schlecht,
wenn wir das Werkzeug erweitern müssen,
wenn wir Workarounds brauchen,
um Fehler des Werkzeugs herumzuarbeiten oder wenn die Einarbeitung notwendig ist,
neuer Leute,
all solche Sachen sind dann
besonders auf schwierig
Sehr schlecht bei Mängeln von Modellillierungssprache. Werkzeug und jetzt Mitarbeiterkompetenzen.
Also wenn ihr keine Mitarbeiter haben, die mit diesem mächtigen
Werkzeug umgehen können, wird das Ganze sehr schlecht funktionieren.
Soweit die Beantwortung dieser Frage 11. Wir können ja nochmal kurz
einen Blick drauf werfen
Um die Erinnerung zu rufen. Ja,
also was sind Vor- und Nachteile formaler Spezifikationen?
Also für diese ausführbare Anforderungsbeschreibung, für Kriterien der Prüfung,
für die Risiken eines Projekts und für die Effizienz des Entwicklungsprozesses.
Nun lassen Sie uns nochmal zurückspringen. Wir hatten ja
die zweite Seite noch nicht bedient. Wir hatten bis jetzt
nur gesagt, was ist denn auf der Seite mehr Modellierung?
Ja, also Modellierung auch so weit treiben, dass wir
sie sogar prototypisch in Simulation oder gar komplett ausführen können.
Weniger Modellierung würde bedeuten, wir haben Vor allen Dingen so
was wie Grafiken zur Kommunikation. Ja, vorrangig würden wir
uns dann da bewegen, wo wir die Modellierungskategorien A und B haben. Da springe ich gleich nochmal hin. Ja,
also hier, dass wir an diese Malwerkzeuge,
wenn wir es also nur benutzen, eigentlich, um zu malen,
vielleicht die Sachen nicht mal in einem Repositore zusammenführen,
ob wir jetzt A und B nehmen oder auch 10 noch,
auf jeden Fall nicht das Ausführbare, was jetzt die Kategorie D wäre,
dann haben wir, ich mache das mal wieder weg,
dann haben wir hier vor allen Dingen Grafiken,
wäre diese rechte Seite.
Nein, das müssen wir unten bei den Möglichkeiten hinschreiben,
das muss ich also hier mal eine Struktive schieben.
Das kann ich hier zum Glück. So, also das ist
für die Kommunikation vorteilhaft. Wir haben dort Flexibilität. Einfach zu erweitern,
wir können einfach neue Darstellungen hinzufügen, insbesondere dann,
wenn wir freie Mal Werkzeuge haben oder in der Werkzeuge haben,
wo man einfach noch eine Vorlage hinzufügt.
Aber wir wollen das nicht ausführbaren. Wir haben gleichzeitig
vorteilhafte Vorteile für die Verständlichkeit
Vorteilhaft für alle Stakeholder, das ist auch noch ein Punkt,
der uns da sehr hilft, weil wir können Darstellungen wählen,
die für alle Darstellfe, ist alles Stakeholder.
Zum Beispiel durch neue Sichten. Das können wir natürlich nicht
so gut, wenn das alles sehr weitgehend formalisiert ist.
So, damit sind wir am Ende von Abschnitt
3,5. Nein,
das war nicht
Gut, dass mir das noch aufgefallen ist. Wir sind ja hier,
das ist 4, 5. Bitte korrigieren Sie das noch.
Entschuldigen Sie diesen Fehler. Wir sind im Abschnitt 4,
5. Vielleicht war das hier sogar in dem vorhagenden Bild.
Auch falsch. Nein, das war, glaube ich,
nicht falsch. Gut, damit sind wir hier durch.
Vielen Dank