Herzlich willkommen zum letzten Kapitel des Kurses Software-Modell-basierte Softwareentwicklung.
Mit dieser Einheit Model-Driven Development runden wir die Sache auch ab,
in ähnlicher Weise wie beim letzten Kapitel DSL.
Wir bleiben ein bisschen allgemeiner und ich möchte ihn eigentlich ansätze,
zeigen, wohin es weitergehen kann, sozusagen um den Anschluss zu ermöglichen, an aktuelle Technologien.
Gerade in diesem Bereich ist sehr viel im Gange,
das wird in einem halben Jahr die Situation schon anders sein, als sie heute sich darstellt.
Deswegen konzentrieren wir uns hier in dieser Lehrveranstaltung auf die grundlegenden Konzepte,
wie uns unterscheiden die sich,
ich möchte ihnen so ein bisschen eine Art Wegweisung durch die Landschaft geben,
einen Überblick über die Landschaft, über die verschiedenen Ansätze,
um damit sie dort anknüpfende Dinge weiterverfolgen können, die Sachen,
von denen wir heute noch nicht weiß, ich hier in zwei,
drei Jahren entwickeln können, die aber sich im Wesentlichen doch in diese Grundkonzepte einsortieren.
Deswegen gehen wir im Wesentlichen, bleiben wir etwas allgemeiner,
wir reden über die verschiedenen Ansätze, die es geben kann,
wie sich das generell in Modellierung einordnet,
was für Einsatzbereiche es gibt und welche Ansätze das sind und um ganz konkret zu sagen,
wo passiert dort Wiederverwendung, welche Arten von Entwurfsentscheidungen werden dort abgelegt,
wie sehen die aus, damit sie ein bisschen ein Gefühl dafür oder entwickeln,
damit sie darüber nachdenken können,
in welche Richtung das geht.
Als Literatur möchte ich sie insbesondere auf dieses erste Buch hinweisen,
was sie auch herunterleiten können. Im Mudel steht der Link dazu,
das ist das hier. Dort ist es ganz gut gegenübergestellt,
was sind denn die Grundkonzepte, die ihr in diesem Gebiet vorherrschen?
Wir sprechen in der Vorlesung ja nur über Grundkonzepte und was
sind technische Lösungen, die dort natürlich viel weitergehend sind.
Das sind weiterführende Dinge, die nicht direkt zur Lehrveranstaltung gehören,
aber die ihnen bei Interesse dem Weg öffnen, wie es weitergehen kann.
Ja, und natürlich hier die zweite Literatur,
ihr sagt es der Name schon, MDA, das ist der Ansatz,
Model Treffen Architecture, der von der OMG vertreten wird,
der dort vorgestellt wird, im Zusammenhang auch mit Meta-Modellierung,
die wir im letzten Kapitel besprochen haben.
Lassen Sie uns einsteigen damit, worum es dabei geht.
Es gibt ja eine ganz viele Begriffe und diese Begriffe so
ein bisschen auseinanderzuhalten, nicht alle Autoren, nicht alle Leute,
die darüber sprechen, machen das in der Weise.
Das macht es dem Zuhörer, dem Neuling,
ihnen vielleicht schwer, sich da zurechtzufinden, das einzuordnen.
Ja, also zunächst erstmal ist Modelbased Development ein Oberbegriff für alles,
was irgendwie mit Modellen arbeitet. Deswegen Modelbased. Ja,
ich nutze diese Modelle für Kommunikation, für Erzeugung,
für Prüfung. Das ist auch so ein bisschen,
deswegen heißt die Lehrveranstaltung auch so, wir setzen Modelle ein für Kommunikationszwecke,
wie zum Beispiel diese halbformalen Modellierungskalküle wie UML.
Wir setzen sie ein für die Prüfung.
Wir hatten Modeldriven Test gesagt und Modell und Generierung,
das wäre das mit DSL, also hier Erzeugung,
dass der Abschnitt DSL und dieser Abschnitt
Morde driven development, hier steht, ist das nicht Model Base,
sondern Model driven, da steckt das Modell im Kern.
Da ist das Modell nicht irgendwie auch vorhanden,
so wäre das bei dem ersten hier,
sondern hier ist das Modell das, was wirklich den Kern aller Informationen enthält.
Und das wäre zum Beispiel, wenn wir Software richtiggehend erzeugen wollen,
ob das nun mithilfe einer DSL ist,
direkt eine Abfrage macht oder chemische Moleküle darstellt,
da ist das Modell das, was wirklich die Information trägt.
Und da wollen wir natürlich ausgehen, das Ganze für die Experten der Fachlichkeit,
dass die damit arbeiten können, ohne lange Programme geschrieben zu werden.
Das bekommen, also das heißt, in irgendeiner Form muss
hin eine Transformation stattfinden. Eine Transformation des Verhaltens,
also irgendwie eine Abfrage, die ich in meiner fachlichen,
mit fachlichen Begriffen beschreibe und die dann etwas ermittelt oder indem ich
etwas generiere oder auch ein Ablauf beschreibe, ein Worklow beschreibe.
Und das passiert irgendwo in dem technische Lösung. Die Herausforderung
ist dabei, diese Transformation, die wir hier eben dargestellt haben.
Also einerseits haben wir ein fachliches Modell,
ich habe hier immer englische englischen Begriffe immer drunter geschrieben.
Problemdomain, das fachliche Gebiet, ja, Domain,
dieser Begriff beschreibt ja nur Gebiet. Das hatten wir ja
beim letzten Kapitel. Und also das fachliche Gebiet, das Gebiet,
wo das Problem, das fachliche Problem steht und das technische Gebiet,
also Problemraum, Lösungsraum, so haben wir das ja genannt.
Ja, und das ist ja das auf dem nächsten Folie,
sagen wir da gleich noch mehr dazu.
So, und wir wollen, dass das eine in das andere transformieren. Ja,
und die Ziele sind ganz klar, wir haben hier immer mehr,
mehr von Komplexität, mehr von Kosten,
Mehr von Forderungen, ja, und mehr von Änderungen,
insbesondere höhere Frequenz von Änderungen.
Und mit klassischer Softwareentwicklung, also ich beauftrage mal eine Softwarefirma,
die das für mich macht.
Ja, das wird aus verschiedenen Gründen immer schwieriger.
Ja, das Ganze schwieriger zu spezifizieren und schwieriger zu erklären.
Das Ganze, weil es mehr wird, wird das teurer.
Wir wollen, dass es schneller geht für mehr Daten.
Ja, und wir wollen überhaupt schneller umgesetzt bekommen.
Nun werden Sie sagen, ja, klar, Scrum,
mach das, da haben wir nach einer Woche eine Ergebnisse im nächsten Sprint.
Ja, das prinzipiell schon,
aber für komplexe Probleme wird das schwierig
Und wenn ich dann viele Teams habe, die irgendwie zusammenarbeiten,
wird die Kommunikation auch schwierig. Am besten wäre es doch,
wenn ich diesen von der Idee desjenigen, der dort eine Versicherungsregel entwickelt,
oder ein Intro für einen Entruischen Detection-System, zu sagen,
das und das, daran könnte ich jetzt einen Angriff erkennen,
wenn wir da nicht sagen müssen, okay,
und diese Regel, die geben wir jetzt im Softwareentwickler,
der entwickelt die, der testet die und in der übernächsten,
in dem übernächsten Release unseres Intuition-Detection-Systems haben wir die dann drin.
Nein, am besten wäre es doch,
wir würden jemanden in der fachlichen Gebiet mit fachlichen Begriffen,
dieses Eindringen und die Art von Meldung in den Logfiles beschreiben lassen.
Wir drücken auf den Knopf oder unmittelbar,
wir speichern und schon werden diese Regeln angewendet.
Und dazu brauchen wir eine Transformation, eine Transformation in eine technische Lösung.
Wenn wir das handwerklich machen, dann dauert das ein Weiler,
ja, dieser Mensch möchte auch bezahlt werden, der das macht.
Und wir haben natürlich das Risiko, dass es in gewisser Weise
falsch läuft. Wenn wir das Automatisier tun, ja,
dann müssen wir eine Investition machen in irgendwie eine technische Lösung,
Technische Lösung muss auf Prinzipien basieren.
Ich habe das hier mal Systematik genannt, also eine Art und Weise,
wie diese Transformation aus fachlichen Begriffen, zum Beispiel solche intruischen Detection-Regeln,
wie werden die umgesetzt in einer Abfrage von Logfiles.
So, und natürlich das Werkzeug, was das tut,
muss auch noch da sein. Wir brauchen,
dass er also das Ganze funktioniert nur,
wenn wir beides zum Spielen bringen und eine Investition kommt zum Spielen,
wenn wir ein gutes Aufwand nutzen Verhältnis haben.
Also in einem Unternehmen wird immer gefragt, return on invest.
Also ich investiere hier 10.000 Euro,
wann kriege ich das Geld dann wieder
Und wenn ich zum Beispiel,
wir sind der Anbieter einer solchen intrusischen Etection-Lösung und wir sagen können,
wir sind sofort nach zwei Stunden und es schickt jemand so ein Angriffsszenario.
Wir analysieren das, wir haben es verstanden und sofort nach
zwei Stunden hat der Anwender eine aktivierte Lösung,
die das findet und die ganze andere Welt auch noch.
Dann sind wir vorne dran, dann sind wir im Markt
die Nummer eins. Ja, und dann würde der Nutzen
vielleicht darin sehen, dass wir vielen mehr Marktanteil haben.
Und dann wären 10.000 Euro auch gut angelegt, das Geld.
Oder 100.000, wenn wir so eine regelbasierte Lösung zum
ersten Mal bauen
Ja, das ist diese Frage der Investition. Wird das
in irgendeiner, durch ein Geschäftsmodell unterstützt? Und das Ganze,
wir brauchen in irgendeiner Form eine Technologie, einen Ansatz,
ein Regelwerk. Ja, und wir brauchen eine Implementierung dafür.
Und was da eigentlich dahinter steht, wir müssen diese Transformation schaffen
von der Formulierung einer Regel zur Suche in eine Lockfile.
Das mit dem Lockfile war jetzt ja nur ein Beispiel.
So, also es geht um Problemraum, Lösungsraum.
Das zeigt uns die nächste Folie und wir beantworten damit eigentlich
diese Frage 1 hier
Sie sollten verstanden haben, was ist hier Problemraum,
was ist der Lösungsraum. So, wir gehen zur nächsten
Folie, wo das ein bisschen so spaltenweise gegenübergestellt wird.
Also das hatten wir ja schon mehrfach besprochen. Wir müssen
es aber hier nochmal, hier brauchen wir das nochmal.
Deswegen habe ich nochmal eine Folie dazu mitgebracht.
Der Problemraum beschreibt die Zielstellung, die Aufgabe,
in unserem Fall Intuition Detection, ist beides irgendwie technisch.
Also die Syntrotion Detection ist auch technisch,
aber es geht halt nicht um Softwareentwicklung,
es geht um Kommunikationsprotokolle, um Ereignisse,
die dort passieren, um vielleicht Rufe,
System Calls,
die aktiviert werden
Also ich muss dann beschreiben, was dort genau passiert.
Und ich muss fachliche Zusammenhänge beschreiben. All das ist Problemraum
. Der Lösungsraum wäre, wir haben das technisch realisiert.
Ja, wir beschreiben, wie das intern passiert,
wie arbeiten wir mit den Logfiles, wo wird das abgelegt,
wie werden Regeln parallel verarbeitet, irgend sowas.
Und das sind auch die technischen Zusammenhänge. Das hat ganz viel damit zu tun,
dass wir auch technische Anforderungen, technische Lösungen realisieren für fachliche Anforderungen.
Zum Beispiel kann es sein, dass wir sagen,
ja, dieses Ur-Prüfungssystem muss auch unter Hochlast im Weihnachtsgeschäft,
wo wir 10.000 Hits pro Sekunde haben,
in unserem Shop-System oder was auch immer,
muss es noch zuverlässig funktionieren und darf keine Verzögerung mehr als,
sagen wir, zehn Millisekunden bringen.
Und da müssen wir deine technische Lösung finden, die diese zehn Millisekunden realisiert. Ja,
die nicht länger aufhört, nicht, dass wir sagen,
okay, wir nehmen das erst mal die Anfrage,
da interpretieren wir die Anfrage, was würde die denn jetzt tun?
Und so lange halten wir die zurück und wenn wir ermittelt haben,
die ist gut, die ist nicht bösartig,
erst dann schieben wir die weiter und wird ausgeführt.
Funktioniert nicht. Wirklich die zehn Millisekunden nicht erfüllen. So,
zu diesem Problemraum gehört mehr als nur das Fachliche,
diese Funktionalität, von der ich eben gesprochen habe,
mit diesem intuition Etection Beispiel.
So, und wir müssen auch noch sagen,
wie ist denn das eingebettet
Wer darf darauf zugreifen? Woher kommen die Informationen? Wie
funktioniert das zum Beispiel mit Zugriffsschutz und Lizenzverwaltung? Ja,
also es kann ja wohl, es darf nicht sein,
dass wir zum Beispiel, wir haben einen Versionswechsel und wir
geben denen raus und auf einmal heißt es bei den Leuten,
ja, ihr habt keine gültige Version,
weil da ein kleiner Fehler passiert ist.
Und dann steht deren ganzes Websystem.
Das wäre ganz geschäftsschädigend. Also diese organisatorische Umfeld,
dann müssen wir in irgendwas uns Gedanken machen über Robustheit,
Ausfallsicherheit. Ja, wie machen wir einen Buypass,
wenn irgendwas mal nicht funktioniert
Und wir müssen jetzt als Beispiel, ja,
wir könnten jetzt auch noch sagen,
wie könnte das fachlich im Finanzwesen aussehen?
Was wir, was wir hier auf der Lösungsraumseite haben,
müssen wir natürlich sagen, wie ist das System technisch aufgebaut?
Wo haben wir einen Cash für schnelle Zwischenspeicherung?
Wo haben wir einen Load-Balencer, wenn mal viele Anfragen kommen?
Wie ist das Ganze organisiert, vielleicht Beer-to-Peer oder in
der Cloud oder wie auch immer?
Wie sind wir datenspeichermäßig organisiert? Gibt es dort eine Replikation
zwischen verschiedenen Datenspeichern? Wie wird Synchronisation von Front and Backend
Oder für Fehlerbehandlungen, wie wird das ein Fehler ausgelöst,
wie wird da verfolgt, wie werden viele akkumuliert und häufige Fehler dann im Monitoring angezeigt.
All das wären technische Lösungen, die zu fachlichen Sachen zugehörig sind.
So, also soweit, damit sollten Sie verstanden haben,
was ist beides Problemraumlösung, sondern was macht jetzt Modeltreffen,
also zwei Folien zurück, dieser Pfeil hier oben.
Ja, diese Übersetzung von dem einen in das andere,
das zeigen, das möchte diese Folie zeigen,
wir müssen diese semantische Lücke betreiben, betrachten als etwas,
wo wir fachlich zu technisch eine Abbildung machen.
Und wir abstrahieren am Ende von einzelnen technischen Lösungen und sagen,
insgesamt funktioniert das so. Darauf machen wir diese Reaktion.
Oder das sind die Zustände in meiner Domäne.
Das sind die wesentlichen Geschäftsprozesse. Das sind die wesentlichen Services.
Und diese Services kann ich in einer gewissen Weise kombinieren,
konfigurieren, was sind mögliche Parameter.
Und das ergibt dann eine Architektur. Also zum Beispiel,
ich habe einen Satz von Services,
die mehr oder weniger
parallel liegen
Das wäre eine mögliche Architektur. Oder ich habe eine Pipeline von Operationen.
Das wäre auch eine mögliche Architektur. Das hängt sehr davon ab,
was wir für adäquat finden für das, was wir dort machen wollen.
Soweit, wir müssen erstmal die Konzepte entwickeln. Und das ist
diese Abstraktion. Und dann brauchen wir etwas zum Transformator. Und auch dieser,
jetzt möchte ich mal einen Rückschritt Rückbegriff machen auf das,
was wir beim letzten,
letzte Woche mit DSLs haben und mal zu den DSLs zurückschalten,
da hatten wir eigentlich genau diese Einteilung.
Da gab es diese Folie mit erstens, zweitens,
drittens, ich zeige die mal kurz
Hier hatten wir genau dieses, die Abstraktionen gewinnen hier.
Das war eine der Möglichkeiten, nein, ich möchte die
eigentlich nicht drin rummalen, das machen wir wieder weg.
Leserpointer reicht hier, ja. Also das wäre dieser Schritt
Abstraktionen und das wäre dann dieser Schritt, ich mache damit etwas.
Eigentlich hier unten, ich entwickle ein Werkzeug,
das ist dann dieser Transformation, hier zwischendurch die Entscheidung über die Technologie,
das hatten wir jetzt hier nicht.
Also wir technische Realisierung wertet die mittleren Schritte und da entsteht dann irgendetwas.
Ja, und wir entscheiden am Ende Wie realisieren wir das
technisch? Und wird das Technische für diese technische Realisierung,
die wir hier brauchen, haben wir ein bestimmtes Schema?
Zum Beispiel für unsere Entrusion-Detection-Regeln gibt es vielleicht drei Sorten von Regeln.
Welche, die greifen, überwachen Protokolle?
Welche, die überwachen Quellen und welche überwachen Ziele?
Also welche Services werden da aufgerufen? Nehmen wir mal an. Und
für diese drei Sorten von Regeln habe ich unterschiedliche Erkennungsschemata,
habe ich unterschiedliche Schemata, wie ich damit umgehe,
wie ich handle, weil ich will ja das Ganze,
die nehmen wir, denken wir wieder an die Pramilie,
die guten Verzögerungen, die wir nur haben dürfen.
Das heißt, wir haben für jede dieser drei Techniken,
haben wir eine bestimmte Art und Weise
damit umzugehen
Wenn das so ist, dann mache das so.
Das sind sozusagen Regeln, Rezepte. Und das sind Entwurfsentscheidungen.
Sie kennen so was Ähnliches von Objekt relationalen Mapping bei Datenspeicherung. Ja,
ich habe ein fachliche Klasse, diese fachliche Klasse wird vielleicht
Trepper sind durch eine Objekte und jede Tasche, Tasse.
Und da, äh, klasse, sorry. Und dafür,
und in der relationalen Datenbank habe ich dafür eine Edity.
Die Edity hat Relation, die hat Attribute.
Und das Ganze wird aufeinander abgebildet
Das ist der ganz einfache Fall. Schwieriger wird es,
wenn mehrere Tabellen ins Spiel kommen. Auch dafür habe ich
eine bestimmte Regel, wie ich das immer wieder mache.
Und ich mache es immer wieder gleich.
Und das ist die Entwurfsentscheidung. Und das passiert so lange,
wie wir das relativ im kleinen Rahmen machen.
Und wenn wir plötzlich das richtig mächtig brauchen,
weil total skalierbar und verteilte Datenbanken, dann brauchen wir ganz andere Konzepte für Verteilungen.
Dann brauchen wir ganz andere Konzepte für Synchronisation,
für Replikation und vielleicht auch für das Rollbeck bei einer Transaktion.
Also ich wollte damit sagen, Entwurfsentscheidungen betreffen dann diese Transformation,
wie mache ich das, wenn die Situation so ist,
dann habe ich diese technische Lösung und dann habe ich dieses Design-Pattern,
dann habe ich dieses Protokoll, so etwas.
Ja, so Beispiele hier für Datenbank-Zugriff habe ich ein bestimmtes Framework.
Wenn wir zum Beispiel Hypernate nehmen,
dann ist so der Klassiker unter den Tools für effektrelationales Mapping,
dann ist das unsere Entwurfsentscheidung, wir machen das mit Hypernate.
Und das funktioniert für eine ganz bestimmte Klasse von Voraussetzungen,
ja, da funktioniert das,
bei einer bestimmten Performancebedarf oder bei technischen,
manchen technischen Plattformen geht das halt nicht
Nämlich Möglichkeiten und Grenzen. Es sind ein paar solche Qualitätsmerkmale
angegeben. Also wir haben bestimmtes Zeitverhalten geht das.
Für andere Erforderungen müssen wir etwas anderes überlegen.
Und im schlimmsten Fall geht keins der Standardwerkzeuge. Und wir
müssen dort eine eigene Lösung bauen. Maßnahmen bei Kommunikationsfehlern,
ja, wir haben irgendwie dieses OSI-Schichtenmodell, sagt,
wenn ich dann auf der Ebene was abreiße,
dann versuche ich wieder und auf der Ebene sende ich einfach nochmal.
Und auf der Ebene weiter unten ist nur Podcast,
ich kümmere mich gar nicht drum, ob es ankommt.
Das sind verschiedene Art und Weise, wie ich damit umgehe.
Auch das ist, wie gehe ich damit um?
Es sind bestimmte Regeln, ich mache das immer so,
so Rezepte
Und diese Rezepte betreffen und jetzt wieder zurück zu diesem Bildchen hier.
Die betreffen diese Transformation. Wenn die Situation so ist,
habe ich diese Lösung. Und das sollte die Antwort sein
auf die Frage mit dem Problemraum und Lösungsraum. Ja,
und jetzt wollen wir uns verschiedene von solchen Techniken mal anschauen.
Dazu haben wir, wenn wir von Abstraktionen sprechen,
ja, und wir wollen versuchen, Modelle so zu machen,
dass sie verschiedene Bedingungen auf technischer Seite passen
Ja, also das heißt, die Abstraktion soll darin bestehen,
dass das Modell in gewisser Weise Plattform unabhängig ist.
Sowas kennen Sie auf jeden Fall schon. Haben Sie schon
mal gehört, zum Beispiel Geschäftsregeln. Das ist eigentlich egal,
ob ich die dann im Prolog, in meiner Regelsprache programmiere
oder einfach hart in Sie-Sharp codiere oder irgendwie interpretiert aus XML,
also im XML-Dialekt auswerte.
Das ist erst mal egal. Ich habe die Regeln als
solche. Die Regeln enthalten so, wenn dann,
wenn dann, tu irgendwas,
das ist ein Ereignis und eine Aktion und vielleicht noch Bedingungen
und sowas hinter Ort
Beispiele hier, dieses Object Regulational-Mapping oder für Workflows,
gehe ich davon aus, dass die Services,
die ich da im Workflow ineinander setze,
in gewisser Weise eine Schnittstelle haben,
dass sie in gewisser Weise Verurteilung sorgen und die Kommunikation zwischen den Services in gewisser Weise funktioniert.
Und damit habe ich ein einheitliches Schema,
dieses einheitliche Schema ist sozusagen, das Wiederkehrende, das ist das,
was ich sage, die Entwurfsentscheidung ist schon getroffen.
Nämlich, dass ich Regeln in der Form erbilde.
Und das geht für eine ganze Klasse von Anwendungen.
Wir hatten hier vorher solche Möglichkeiten und Grenzen genannt. Ja,
also wenn wir ein weiteres Zeitverhalten wollten,
wenn wir zum Beispiel total schnelle Regeln haben wollen,
geht das vielleicht nicht mit der Implementierung,
die wir bis jetzt hatten
So. Also, das ist die Abstraktion. Und auf dieser Plattform
übergreifenden Lösung sehen wir nichts davon, wie das technisch funktioniert.
Das Technische ist sozusagen versteckt. So. Und die technische Realisierung,
die setzt dieses Schema um. Dieses Schema muss irgendjemand kennen
. Und jetzt kommt der Punkt, wo wir über,
als diejenigen, die so eine Technologie entscheiden wollen,
darüber entscheiden wollen, ob sie einsetzbar.
Wir müssen wissen, was ist denn die technische Realisierung?
Wir müssen wissen, was sind denn die Möglichkeiten und Grenzen
Manchmal steht es bei den Tools,
wird es bei den Tools mitgesagt, ganz häufig aber nicht,
weil natürlich die Toolhersteller es gern verkaufen wollen und nicht so viele Grenzen nennen wollen,
die muss man dann irgendwo herauskriegen.
Und der Transformator arbeitet nach diesem Schema,
man kann ja auch sagen, immer nach Schema F,
so ein Hypernet arbeitet, Hypernet ist ein sehr mächtiges Werkzeug,
ich kann das parrametrieren, kann verschiedene Schematape folgen,
aber im Prinzip können wir sagen,
es ist immer Schema F.
Da gibt es noch F1 bis 16 vielleicht,
aber es gibt immer das gleiche Schema.
Und dieses Schema, das müssen wir halt kennen,
müssen wir verstanden haben.
Und jedes dieser Schemen hat Möglichkeiten und Grenzen
Soweit erstmal, wie dieser Transformator arbeitet,
dass er eigentlich doch relativ stumpf dieses Schema abarbeitet.
Und was muss der Transformator denn eigentlich können? Dieser Transformator
muss zunächst erstmal korrekt arbeiten. Bleiben wir bei diesem Geschäftsregelbeispiel,
er muss korrekt diese Geschäftsregeln abbilden. Es darf nicht irgendwie davon abhängen,
sowas passiert immer, dass die Geschäftsregeln,
die werden quasi täglich oder wöchentlich geändert in Details,
dass wenn ich die irgendwie in der Reihenfolge ein bisschen männer darf,
nicht irgendwas ganz anderes rauskommen
Oder sowas. Also das passiert aber. Deswegen müssen wir schauen,
inwiefern ist das korrekt? Vollständig. Ist das sozusagen?
Manchmal sagt man sehr oft Contained. Ist das wirklich komplett
die Beschreibung da drin? Ist es reproduzierbar? Das,
was wir hier machen. Und die Regeln folgen irgendeiner Grammatik.
Wir haben ja den Begriff Meta-Modell, wird wirklich alles,
was die Grammatik ausdrücken kann, von dem Transformator auch verstanden.
Nicht, dass ich irgendwas mache,
was eigentlich zulässig ist, eine bestimmte Kombination von Typen.
Und dann sagt er, Transformator, nee,
verstehe ich nicht.
Fehlermeldung kann ich nicht verarbeiten
Und das Ganze soll natürlich funktionieren für die Sachen,
die in unserer Domäne wichtige Aufgaben sind.
Und dazu haben wir letztlich am Ende Lösungen auf Vorrat geschaffen.
Wir haben Lösungen geschaffen für dieses Schema F,
das zum Beispiel objektralationalen Meppings oder für das Schema F,
wie gehe ich mit diesen drei Typen von Enthuschen Problemen um?
Und häufig ist damit implizit, das heißt nicht genau beschrieben,
irgendetwas zu Qualitätskriterien gesagt, wiederum, das war das,
was wir auf der Folien vorher hatten, diese Qualitätskriterien hier.
Ja, da ist irgendwelche Möglichkeiten und Grenzen,
die waren irgendwie klar, als jemand diesen Transformator entwickelt hat.
Und wir müssen dann diesen Transformator entsprechend bauen oder wir müssen
beim Anwenden des Transformators wissen, wo seine Möglichkeiten und Grenzen sind.
Soweit der Antwort an den Transformator,
der Transformator soll zum Beispiel das Meta-Modell ganz konkret beschreiben,
umsetzen und dieses Meta-Modell ist ja das,
was am Ende die Problembeschreibung erlaubt.
Damit beschreibe ich,
was ist eigentlich meine Aufgabe
Ganz egal, ob das jetzt Regeln für objektreditionales Mapping sind oder Datenstrukturen,
sondern oder ob es Regeln für indurchschnittdection sind oder was anderes.
So, das waren die Anforderungen an den Transformator.
Und jetzt noch Anforderungen an das Meta-Modell. Und das
ist ja letztlich die Menge der möglichen Kombinationen des Input.
Also die fachliche Abstraktion. Am Ende ist also das Meta-Modell
irgendwie, es geht um fachliche Abstraktionen.
Und diese Abstraktionen sind deswegen irgendwie, die sind deskriptiv.
Die sind meistens nicht imperativ. Ich sage, und ich
mache halt erst das, das gibt es natürlich auch.
Aber es gibt keine Möglichkeit, wirklich das zu testen.
Sondern ich kann nur sagen, ja, es ist adäquat,
es ist passend. Das hatten wir letzte Woche auch,
also über domainspezifische Sprachen gesprochen haben, haben wir auch gesagt,
was Sie erinnern sich vielleicht an diese Frage,
die wir da hatten, wann sind domänspezifische Sprachen,
denn korrekt?
Gibt es sowas korrekt? Was sind Qualitätskriterien, hieß das Ganze?
Wir gehen mal, ich gehe mal zurück zu den Folien
von letzter Woche und da gab es hier diese Frage,
Qualitätsanforderungen von domänspezifischen Sprachen, ja.
Und da war Angemessenheit, Korrektheit bezüglich der Semantik, Benutzbarkeit.
Und genau das Gleiche haben wir jetzt auch wieder.
Ja, wir wollen, dass es angemessen ist.
Dass es also passend ist für unsere Domäne.
Beschreibt es alles, was wir dort brauchen, vollständig?
Kann ich alle zum Beispiel Entrusion Etection Situationen damit abbilden?
Wenn nicht, sollte ich mein Metamodell erweitern.
Ja, also das muss erfüllt sein müssen.
Gibt es, ist alles, was dort fachliche Entitäten sind?
Ist das denn beschreibbar? Wenn alles, was an Regeln
sind, ist das denn beschreibbar
Und ist das Ganze mächtig genug. Nicht,
dass ich nach Dreischachtelungstiefen von logischen Ausdrückenden Schluss habe,
und ich brauche aber dummerweise vier.
Und das Ganze muss natürlich auch formal definiert sein,
also das, was ich hier alles möglich habe.
Und Angemessenheit, dass es handhabbar ist für denjenigen,
der damit arbeiten will.
Dass ich nicht den Informatiker dabei sitzen brauche und den Programmierer.
Das wäre ein wichtiger Punkt. So,
bevor wir weitermachen mit Ansätzen,
beenden wir erst mal das Video und machen den nächsten weiter