Wir hatten jetzt schon darüber gesprochen, wie dieses Übergehen von Problemraum
in den Lösungsraum funktioniert und hatten das auch schon gegenübergestellt zu dem,
wie es in der DSL ist.
Wir haben jetzt hier noch eine Folie, die das nochmal zeigt,
wie das letztlich die Analyse des Problemraums in der Übergang in den Lösungsraum läuft.
Am Ende wären wir ganz viele Ähnlichkeiten. Wir schauen uns das
gleich nochmal an, wie es bei der DSL war,
dieses Schritt der 1 bis 4 lädt sich das ins Gleiche.
Zunächst, wir analysieren den Problemraum, was ist dort zu tun, was für Konzepte existieren
Das ist letztlich das, was wir hier auch hatten,
Analyse, das war der falsche, falsche Spitze.
Wir wollen das gerne mit Zeiger haben.
Die Analyse der Konzepte, der Struktur, der Beziehungen.
Und das ist letztlich das, was wir hier auch machen.
Weil analysieren, was ist in der Domäne zu machen?
Steht jetzt hier nicht so genau da, aber am Ende
ist es genauso. Und dann, was brauchen wir alles
? Das soll ja am Ende der Umfang der Sprache,
der Umfang des Vorrats, was das Werkzeug übersetzen kann.
Dann entwickeln wir irgendwie die Modellierungssprache, die wir brauchen,
Es war letztlich bei DSL auch so, wir schauen nochmal zurück.
Ja, hier war Meta-Modell entwickelt und war dann Schritt zwei.
Das ist jetzt hier nicht nummeriert auf dieser Folie, aber letztlich das Gleiche.
Wir entwickeln dieses Meta-Modell, wir formalisieren. Ja,
und dann geht es schon los, zu überlegen,
wie soll denn das aussehen? Zum Beispiel müssen wir entscheiden,
du solltest textuell oder sollst es grafisch sein, diese,
was bei, was hier vorne dann hieß,
wir wollen nach der abstrakten Syntax, was im Meta-Modell steht,
wollen wir dann auch die konkrete Syntax entwickeln.
Grafisch, textuell, wie auch immer. Und jetzt hier
, dann sollten wir versuchen, irgendwie Wiederverwendung zu machen
Verwendung, indem wir bestimmte, wir hatten eben gesagt,
es gibt gewisse Rezepte, die immer wiederkehren, dieses Entwurfswissen,
dass wir das nutzen, um bestimmte prinzipielle Vorgehensweisen,
Bausteine, Designpatterns, dass wir Produkte einsetzen,
die zum Beispiel für Mustersuche geeignet sind,
dass wir was einsetzen, was für Übersetzungen geeignet sind.
Und natürlich manchmal auch abstraktere Dinge wie Prinzipien oder Designpattern,
die noch implementiert werden müssen.
Oder manchmal können wir auch uns an eine Referenzarchitektur anlehnen.
Ja, das sind dann die Entwurfslösungen, die Vorgefertigten,
die wir dann einfließen lassen Und dann wird das eigentliche Teil entwickelt.
Das war bei dem DSL-Beispiel auch dann hier und hier.
Es ist natürlich irgendwie ein Übersetzungswerkzeug. Während sie hier mehr so
ein Transformator oder Generatorwerkzeug ist. Am Ende soll etwas rauskommen.
Am Ende kommt eine Konfiguration zum Beispiel raus für eine Webseite.
Oder es kommt eine Konfiguration raus für irgendwelche Regeln. Oder ein Regelinterpreter,
das ist etwas eher, was interpretativ abarbeitet oder etwas,
was etwas ein Code generiert, wie für eine HTML-Seite.
Ja, also das wären alles Möglichkeiten. Und am Ende diese Entscheidung,
ob wir textuell oder grafisch machen, die betrifft dann die Werkzeugauswahl.
Die betrifft das, was wir dann tun. Und weil,
wie das hier unten aussieht, und das ist ja das,
was wir uns an deren Technik, anhand der Techniken anschauen wollen.
Wir starten jetzt mal mit Model-Treffen Architecture. Dieses Model-Treffen Architecture
ist etwas, was zunächst erst mal als Name daherkommt.
Und zwar den Namen wollte gern die OMG prägen,
OMG, sie erinnern sich, das waren ja die,
die UML definiert haben.
Später UCL und später auch Süßemelde. Ja,
die Object Management Group, die wollte einen Standard schaffen,
Standard hat immer irgendwas zu tun
Mit Austauschbarkeit, insbesondere Austauschbarkeit zwischen Plattformen,
also zwischen Tools, dass ich also einen Generator,
der zum Beispiel Webseiten generiert, dass der das die gleiche,
ich muss in den Dialog ja in irgendeiner Form beschreiben,
was ist da alles drauf,
welche grafischen Elemente und dass die gleiche Beschreibung für den einen und den anderen Dialog,
die Generator passt.
Ja, Portabilität sozusagen zwischen den Werkzeugen. Das wollten
die erreichen, das war das Ziel davon. Klar,
dass sie auf das basieren, was sie vorher schon,
was es vorher hat, so im Portfolio gibt,
nämlich das wäre die UML als ein Ausdrucksmittel für viele Dinge,
wie Abläufe, Strukturen und so etwas.
Natürlich taugt das nicht dafür, grafische Elemente zu anzuordnen.
Da brauchen wir noch was mehr. So, dann,
wie beschreibt man das Meta-Modell, was wir da zu beschreiben haben?
Das war ja, nein, anderer Seite, ja,
wir brauchen ja hier irgendwie ein Meta-Modell und dieses Meta-Modell machen wir
natürlich auch mit dem, was die OMG da hat,
diese fünf Ebenen und da war dieses Moph-Meta-Object Facilities,
das Ding.
Ja, das ist einfach das Format. Wir hatten ja gesagt,
diese IQ-Dateien, am Ende ist das ziemlich ähnlich zu dem,
was BNF, Pacus Norrow-Form ist.
Also die Sprache zur Karottenbeschreibung von Grammatik und dann für
diesen Austausch
Waren sie, haben sie gesagt, okay, dann nehmen wir das XMI,
was wir für UML ja schon definiert hatten, als Austauschsprache.
Als für den Datenaustausch zwischen Modellierungswerkzeug, zwischen Modellierungswerkzeugen,
für Grafiken, Modellierungswerkzeugen verregeln oder was auch immer. So,
das ist, das ist soweit erstmal der Ansatz und dann das,
was die Begriffe, die sie geprägt haben und die Ideen,
die sie verfolgt haben, bestimmen am Ende dafür auch die Anwendbarkeit.
Das ist ja, wenn wir mal zu den Fragen zurückspringen,
die zweite Frage hier, Einsatzbereich,
das ist ja das,
was wir
jetzt hier diskutieren wollen
Nein, nächste Seite. Der Einsatzbereich ist dadurch bestimmt was
, wie wir es machen. Und hier haben wir,
gibt es als Begriffe, die möchte ich kurz erläutern,
dass Plattform Independent Model PEM, Plattform unabhängiges Modell,
das ist zum Beispiel so eine Grafik-Layout-Beschreibungssprache für einen Bildschirm,
für einen Dialog.
Oder Regeln für das Intrusion-Detection-System. Oder Datenstrukturen für die Objekt-reelutionalen
Mapping. Also wir beschreiben etwas im fachlichen Bereich und das
ist unabhängig von der Realisierung.
Das soll dieses Platform Independent heißen
Das Gegenteil davon ist Platform-Specific. Ja,
also das ist dann angepasst für ein bestimmtes Werkzeug.
Wir haben zum Beispiel da am Ende HTML mit Style-Sheets für
den und den Browser oder für den oder eine Gerenrate,
eine Sprache für das und das, Gui-Tool-Kit,
um da eine Webseite oder einen Dialog draus zu generieren.
Und das ist dann so und diese Übersetzung zwischen dem und dem,
das soll passieren, aufgrund einer formal beschriebenen Struktur,
was die Architektur denn kann und wie sie dazu hinkommt,
dass das Plattform spezifisch ist und das ist dieses Plattform-Description-Model.
Das hatten wir tatsächlich bei Teil 11 schon mal.
Das war dort die Folie-Elf. Wir springen mal schnell hin
. Diese Folie zeigte uns das damals schon.
Damals ging es ja uns vor allen Dingen um diese Ebenen.
M1M2, M3. Das interessiert uns jetzt nicht so sehr.
Aber hier haben wir halt, das war wieder der falsche Stift.
Hier haben wir diese, das Plattform in unabhängigem Modell und das Plattform spezifische Modell.
Beides sind eben Modelle auf dieser Modellebene des Meta-Modells.
Ja, und das Plattformunabhängige,
das wird transformiert
In ein Plattformspezifisches Modell. Und diese Transformation,
so formuliert das die OMG, das ist das, das,
wo wir diese allgemeine Regelsprache zum Beispiel anpassen auf ein bestimmtes System,
was dann diese Regeln auswertet.
So, und diese Transformation wird dann mit den Plattform Specific Model gemacht.
Also das restliche Diagramm zeigt eben nur, okay,
für dieses PEM haben wir eine Grammatik und für das PSM
haben wir eine Grammatik und die Grammatik wird mit Moff beschrieben,
die Grammatikbeschreibungssprache.
Das interessiert uns jetzt nicht so sehr,
sondern eher so,
was kann man
damit machen
Und das ist jetzt auch der Punkt,
wo ich kurz was dazu sagen möchte,
was denn die Leistungsfähigkeit dieses Ansatzes hier mit PEM und PSM ist.
Tatsächlich ist es so, dass er sich so breit
wie die OMG, das wollte er nicht durchgesetzt hat.
Sondern, gut, es gibt natürlich auch noch viele
konkurrierende Ansätze, die dann noch was anderes machen wollten.
Hier ist es ganz gut dafür, wenn wir relativ einfache eins zu eins Beziehungen haben.
Also wenn man ganz klar sagen kann, die Regeln werden so umgesetzt.
Wenn wir ganz viele Sachen haben, die miteinander,
die dann auch Auswirkungen haben, zum Beispiel,
ich möchte, wenn der Level von Security anders ist,
dann brauche ich eine andere Architektur
Oder wenn der, wenn der Grad der Ausfallsicherheit Availability anders ist,
brauche ich eine andere Achitektur, dass ich dann ganz andere Regeln brauche.
Dann ist es nicht genug gewesen, dass mit dem Plattform Description Model zu beschreiben.
Das sind ein ganz wesentlicher Punkt, wo das dann nicht
richtig geklappt hat. Und weitere wesentliche Punkte sind,
es gibt da noch mehr, ich möchte nur das nennen,
dass dieses XMI tatsächlich eben doch sehr von den Herstellern ein bisschen vergewaltigt wurde,
dass es doch nicht so gut zum Austausch geeignet wurde.
Wir hatten ja schon im Seminar darüber gesprochen und erübung darüber gesprochen,
dass das XMI doch nicht so gut das darstellt.
Soweit der Ansatz Model trifft ein Architecture. Als nächstes möchte ich
zu gut Generatoren kommen. Kurt-Generatoren sind auch ein Ansatz,
wo wir etwas wiederverwenden. Hier war es also im Wesentlichen diese Plattformbeschreibung,
die wir dein Touilla verwenden, um das Plattformspezifische zu generieren.
Und hier haben wir die Regeln, die dann ein bestimmtes,
wenn die Regel kommt, kommt das Stück holt,
oder bei dem Input kommt der Output.
Das ist letztlich das,
was wir bei Kurt-Generierungen machen und da letztlich auch wieder,
wie immer, wir haben eine Beschreibung des Fachlichen,
was es sein soll, das ist das Modell des Proben,
das Problemraums.
So. Und mit Coden meinen wir nicht nur sowas wie Java oder Cishape oder C,
sondern mit Coden meinen wir durchaus auch etwas,
wo nur etwas Diskutives ist.
Zum Beispiel Konfigurationen. Ja, also wir konfigurieren zum Beispiel
die Gui-Bauesteine um einen Dialog darzustellen.
Ja, was kommt wohin? Was hat welche Parameter?
Das eine hat einen Rand, das nächste hat keinen Rand.
Das schiebt sich dahinter. Das sind letztlich Konfigurationen. Ja
, das können wir zum Beispiel sagen. Oder ja,
Oder bei Workflow-Systemen, wo wir letztlich Services aufrufen in einer
bestimmten Reihenfolge mit bestimmten Parametern und diese Aufrufe letztlich nur beieinander platzieren.
Das ist jetzt nicht direkt Umsetzung in eine Sprache.
Auch eher so eine Reihenfolge von Aufrufen. Oder dass wir
Quellcode-Bausteine zusammensetzen, Templates zusammensetzen, die dann wiederverwendete Bausteine sind.
Und dazwischen gibt es noch Dinge, die nicht wiederverwendbar waren,
die man von Hand geschrieben hat.
Und die beiden Leuten Generationen einfach wieder eingefügt werden,
die man hoffentlich nicht neu schreiben müssen
So, und es gibt, das ist die eine Möglichkeit.
Wir konfigurieren etwas. Das heißt, wir gründen generieren nicht ganz,
sondern wir setzen eigentlich Teile zusammen und sagen, wie das genau passiert.
Also wir generieren die Parameter. Wir können natürlich
auch direkt Quellcode generieren, der auch in Bausteinen kommt.
Da gibt es bestimmte Fragmente für das, für das, für das.
Und damit führten wir auch zu einer Übersetzung. Oder,
was auch eine gängige Technik ist,
dass wir so eine Art Prä-Prozessor haben,
so ähnlich wie der CP-Prä-Prozessor von CPlus Plus,
der dann erstmal zu C übersetzt,
Da könnten wir auch einen Pre-Prozessor haben, der das übersetzt.
Das hatten wir hier, war das kurz dargestellt. Also wir haben das,
wo wir wirklich in Form von Meta-Programmen etwas beschreiben, was da passiert.
Oder dass wir einen Pre-Prozessor haben, der Anweisungen hat,
wie die Ersetzungen zum Beispiel enthalten. Ja,
dazu könnte man auch Templates ganz gut verwenden für die Teile,
die immer gleich bleiben, wo dann Stellen sind, die ich ausfülle.
Also wie so eine Art Lückentext, wo sie an den Stellen etwas reinfüllen.
Das klassische Dieses Template würden wir dann irgendwo hier bei den Meta-Programmen
mit vorsehen oder je nachdem, wie das angesteuert wird.
Tatsächlich sind diese Templates eine sehr gängige Methode. Ich würde mal damit anfangen,
das zu, als Beispiel das zu sagen,
so ähnlich wie das für einen Lückentext ist,
den wir zu einem Serienbrief machen.
Ja, da steht irgendwie, oben gibt es Adresse,
da ist jede Adresse anders und dann kommt Rechnungsnummer und sehr gerne Damen und Herren,
bitte bezahlen Sie folgende Rechnung bis zum so und so vierten.
Das so und so viele
wird wieder eingesetzt
Der Text wird erst Tabelle, vielleicht welche Positionen gibt es
da, welche Summe, welche Mehrwertsteuer wird eingesetzt.
Und dann gibt es wieder ein paar festen Teile,
zum Beispiel unsere Zahlungsdaten sind, die und die Kontonummer und das und das.
Und die alten Gemeindengeschäftsbedingungen haben sie zugestimmt und bla bla bla.
Also es gibt konstanten Code und angepassten Code. Und das ist eben,
wenn wir einen hohen Anteil einen statischen Code haben,
der immer wieder gleich ist,
dann kann ich das ganz gut mit diesen Templates machen,
wo ich nur an bestimmten Stellen die Variablen Teller einfüge.
Und diese werden durch das Template definiert, diese Stellen,
wo ich anpasse oder übernehme.
Meistens sind das Text und man macht das heute sehr immer
diesem XML-Stil
Ja, also Spitzenklammern und Tech-Anfang, Tech-End für Ende.
Und der Template-Engine ist eigentlich so ein Ersetzungswerkzeug. Das fügt Dinge
immer zusammen und für jeden Ausdruck ist das einmal drin.
Wie bei einem Serienbrief, da geht so eine Rechnung wird
hundertmal rausgeschickt und jedes Mal eine andere Adresse,
ein anderer Inhalt, anderer Betrag.
Und entweder werden die Inhalte erzeugt oder nur eingesetzt aus einem
anderen Modell und das wird dafür genommen.
Ganz viel hat man das für Webseiten,
wo wir einen hohen statischen Anteil haben für den ganzen Vorspann,
für den Rahmen und dann nur die Inhalte werden ein
bisschen angepasst
Oder zum Beispiel für Testfälle, wo wir den Vorspann,
ich muss etwas aktivieren, etwas aufsetzen, initialisieren, erzeugen.
Das ist immer gleich, nur die Datensätze sind dann unterschiedlich.
Ja, ja, weil Serverpages, ASB, BHB,
XSLT als Transformator für XML, das sind Techniken,
die ich dafür relativ häufig einsetze.
Schauen wir uns mal so ein Beispiel an, wie sowas,
wie sowas aussehen kann. Wir haben hier etwas,
einerseits was generiert werden kann und andererseits etwas,
wo wir sagen,
so soll es sein
Zunächst möchte ich erst etwas zur Struktur seines solchen Systems, in solchen erzeugten Kurz zeigen.
Wir brauchen dazu eine neue Seite. Und wenn wir uns mal das anschauen,
sieht das häufig so aus, dass der Code sich einteilt,
in einen Teil, der schematisch ist,
der sehr gut wiederverwendet werden kann und den wir ganz gut mit dem Generator erzeugen können,
der einen hohen Wiederholgrad hat,
sowas kommt zum Beispiel vor,
wenn wir immer dieses,
was wir bei Templates schon eben gesagt hatten.
Dann gibt es
den Plattform-Code
Dieser Plattform-Code, damit ist gemeint,
dass wir etwas zum Beispiel zum Speichern von Daten für bestimmte Routinen,
die immer wieder gebraucht werden, Utilities, Services, die alle anderen brauchen Basisklassen.
Solche verschiedenen Dinge, die ganz häufig benötigt werden,
aber die brauchen wir, müssen wir nur einmal schreiben.
Und dieser Plattform-Code, der nur einmal geschrieben wird,
den brauche ich natürlich nicht generieren,
der wird dann Der wird dann also von Menschen entwickelt,
von Hand geschrieben, ja, der schematische Code,
das ist etwas mit einem hohlen Wiederholgrad,
den kann man gut generieren.
Der hat einen hohen Wiederholgrad
Und dann gibt es noch Code, den würden wir auch
ganz gerne generieren aus einem Modell, aber der hat einen geringeren Wiederholgrad.
Der hängt auch vom Modell ab, aber der ist Applikationsspezifisch
Und der hat einen geringen Wiederholgrad. Und diesen Code,
da lohnt es sich natürlich nicht, den Generator zu erzeugen,
dass wenn ich etwas nur einmal brauche oder nur zweimal,
ich dann einen Generator für erzeuge,
der das unter bestimmten Bedingungen kann und dann den Generator so weit bringe,
dass er nie Fehler macht,
hoffentlich nie,
dann brauche ich das nicht
Der Generator wäre nicht ökonomisch oder sagt man lieber vielleicht nicht wirtschaftlich.
Und deswegen wird das, auch wenn es vielleicht zwei,
dreimal vorkommt und in bestimmten Varianten von Hand geschrieben.
Dass wir also so das, ich mache in meinen Zeichen,
jetzt sind wir noch dran,
hier vorne noch dran mit das, was Applikationsspezifisch ist,
Und der Plattformen-Code, der ist typischerweise einheitlich.
Für eine ganze Reihe von Applikationen eben deswegen,
weil es die Plattform ist.
So das Gleiche machen wir hier auch noch
so schön
So, das ist jetzt für den, der kommt nur einmal vor,
den nehme ich bei jeder Applikation wieder, den brauche ich nicht zu schreiben.
Es kommt uns also darauf an, dass wir dieses Stück Code hier,
nämlich diesen schematischen Code, dass das einen möglichst großen Anteil ausmacht,
nur für solche Anwendungen lohnt sich das.
Und wir müssen natürlich schauen, dass dieser Teil hier oben,
der einen geringen Wiederholkrad hat,
dass wir den nicht vom Generator erzeugen lassen,
weil ein Generator entwickeln bedeutet sehr hohen Aufwand und wir wollen das gering machen.
Das heißt, wir müssen sehr genau abwägen,
wie weit wir das treiben
Und ich kenne Kollegen aus einem Projekt, die nachrückblickend sagen,
wir haben zu viel generiert. Also dieser Anteil hier,
der war für ein zu großer Teil der Applikation,
da wurde die Sprache zu mächtig, der Generator zu aufwendig.
Am Ende wurden da nur zwei-, dreimal,
wurde der Kurt generiert, der in der Generator kann.
Man hätte das besser von Hand geschrieben. Ja, das wäre
viel wirtschaftlicher gewesen. Und natürlich muss ich versuchen zu ermitteln,
was kommt denn wie häufig vor und nur für diesen chematischen Teil,
lohnt sich ein Generator.
Der würde dann von Hand geschrieben, man würde entweder,
den wird man dann meistens improtected regions packen,
dass er also nicht wieder überschrieben wird
So, der, das notieren wir noch irgendwie noch mal,
ja, das sind hier Realisierung als Protected Regions.
So, zur Frage, die wir ja eigentlich beantworten wollen,
wann setze ich das ein, wann setzt sich diese Technik ein?
Ja, ich setze die ein,
wenn ich einen hohen Anteil von Kot habe,
der schematisch ist und der einen hohen Wiederholgrad hat.
Nur dann lohnt sich ein solcher Generator. Das war die Frage 2
hier. Ja, Einsatzbereiche, wann habe ich das?
Wir hatten das bei den Templates ja auch schon beschrieben.
Ich gehe nochmal zurück zu der Folie, wo sind die Templates?
Ja, wenn ich einen hohen Anteil an statischen Code habe,
nur einzelne Stellen einsätze, dann würden sich Templates lohnen.
Wenn ich einen hohen Anteil an chematischen Code habe,
dann würde sich das Templat nicht so lohnen.
Dann lohnt sich ein solcher Generator
Jetzt zu dem Protected Regions. Vielleicht hat der eine oder andere
schon mal so programmiert. Das bedeutet,
ich habe dort irgendwie einen Tech oder eine bestimmte Kennzeichnung,
das sagen, right, below this line.
Und dann unten irgendwo, wo das zu Ende ist,
don't right, be below this line. Also dieser Teil,
der wird dann sozusagen bei einer neuen Erzeugung von dem schematischen Code hier,
wenn der chematische Code erneut, wird dieser Teil geschützt,
wird aufbewahrt, wird nicht überschrieben.
Soweit, so gut. Wenn sie der Programmierer dieses Teils sind,
dann Haben Sie die Herausforderung, dass Sie oder das Problem, ja,
der Projektleiter sagt ja immer, wir haben keine Probleme, wir haben Herausforderungen.
Also am Ende ist es das Gleiche. Wir haben das Problem,
dass wir, wenn wir hier programmieren, wir nie genau wissen,
unter welcher Situation komme ich denn dahin?
Was ist meine Umgebung? Ich bin sozusagen wie in
einem ringsherum ist es dunkel und ich habe dieses Stück,
was ich sehe und ich weiß nicht, was ringsherum her ist.
Das ist eine Programmierung mit ganz großer Herausforderung. Das heißt,
diese Programmierung, wenn die nur so Predicted Regence haben, das ist tatsächlich
Er fordert halt viele, er fordert viele kreative Fähigkeiten,
um sich genau vorzustellen, unter welcher Bedingung bin ich denn wo.
Sie können natürlich den Code generieren lassen und wenn das dann komplett fertig ist,
können sie einmal per Debucking durchgehen und dann merken sie,
okay, jetzt ist gerade das,
ist jetzt gerade das und unter diesen Bedingungen wird mein Code denn hier aufgerufen,
aber das ist tatsächlich eine ziemliche Herausforderung.
So, jetzt aber das, was die vorgehende Folie zeigt,
die vorgehende Folie zeigt uns sogenannten Dummy-Code,
den würde ich mitgenerieren oder mit hier bei der von Handgeschriebenen Sache mithaben und zwar deswegen,
um zu prüfen, ob denn der handgeschriebene Code,
den die Entwickler dort einfügen,
ob er denn die Antwortungen erfüllt.
Hier in unserem Beispiel haben wir hier eine generierte Klasse,
die soll zusammenarbeiten mit einer anderen Klasse und wir wollen prüfen,
ob bestimmte Bedingungen erfüllt sind.
Ja, also es soll zum Beispiel hier etwas überschrieben werden,
die Klasse soll so heißen und das Interface soll überschrieben werden, ja, sowas.
Und wie machen wir das? Wir setzen den Compiler dafür ein,
um zu prüfen, ob denn diese Teile da sind.
Und zwar haben wir hier so eine,
das nennt sich Dummy Code, der Code wird nirgendwo ausgeführt.
Ganz besonders achten Sie mal hier drauf,
If Falls bedeutet, werden dort nie hinkommen, ja,
aber der Compiler prüft, ob die Bezeichner entsprechend verwendet werden.
Zum Beispiel hier prüfen wir, dass wir, wir erzeugen diese Klasse,
ja, und weißen erzeugen eine Instanz und da prüfen wir,
dass die Klasse überhaupt da ist, dass sie nicht abstrakt ist.
Wir dürfen etwas davon erzeugen. Wir prüfen,
dass die implementierte Klasse tatsächlich eine Sabglas von der anderen ist,
was wir hier damit erwarten, ja, und dann versuchen wir,
dass das wirklich, ob wirklich dieses Interface implementiert wird.
Ja, wir können das dadurch machen, dass wir,
also sonst würde das hier der Compiler meckern, wenn ich das nicht so hätte.
Die Implementierung, die der Entwickler geschrieben hat von Hand,
ja, und das Gleiche prüfen wir noch,
ob tatsächlich dieses XYZ-Operationen da ist, in dem ich so tue,
als würde ich sie aufrufen.
Wie gesagt, das wird nie aufgerufen, weil wir davor falls stehen haben,
aber wir können damit, der Compiler würde meckern,
wenn das hier nicht diese Struktur hat, die wir erwarten.
Das ist sowas, etwas ist notwendig,
sowas müssen sie machen,
weil die Entwickler natürlich auch Fehler machen und das betritt sich dann,
die Fehler,
die hier drin passieren
Ich muss dazu sagen, es passieren auch Fehler, die der Generator macht.
Da wäre dann hier was falsch. Und das ist dann
immer sehr unbeliebt, weil man muss dann in den,
wenn der Generator hier Fehler macht, dann sind die systematischer,
macht die dann immer wieder in einer bestimmten Bedingungen.
Das fällt ihnen schwer, das rauszukriegen. Aber wenn sie es dann rausgekriegt haben,
müssen sie hier rein etwas irgendetwas zur Behebung dieses Fehlers machen.
Ja, und das ist natürlich dann nochmal,
wenn man dann ewig sucht, ist das,
macht das die Sache schwer. Soweit. Aber die wesentliche,
die Bottenline und die Antwort auf die Frage,
warum brauchen wir, wann setzen wir das ein,
wenn wir einen hohen Anteil, einen schematischen Code haben.
So, wir haben jetzt
noch zwei weitere Dinge
Zum einen hier ein Interpreter. Dazu haben wir noch eine Folie
. Was ist der Interpreter? Letztlich ist der Interpreter,
setzen wir den zu den ähnlichen,
zu ähnlichen Bedingungen ein, wie den Kurt-Generator,
nämlich wenn wir einen hohen Anteil von schematischen Dingen haben.
Aber man kann beobachten,
dass er ein bisschen häufiger für Verhaltens- als für Strukturmodelle eingesetzt wird,
also zum Beispiel für solche Workflow-Sprachen, die ich dann interpretiere.
Oder die Abarbeitung von bestimmten Aktionsfolgen,
die Überprüfung oder die Behandlung eines Erzeugens bestimmten Protokolls
Ja, wenn man natürlich einen Interpreter hat, dann muss ich nichts erst übersetzen.
Ich kann sofort, wenn ich etwas geändert habe,
einfach nur starten. Ja, ich muss deswegen nicht,
bin ich ein kleines bisschen schneller, wenn mit meinen Debucking-Zyklen.
Ganz häufig setzt man das auch noch ein,
wenn so ähnlich wie eine DSL sehr fortgeschrittene Benutzer,
die dann immer fachliche Benutzer sind,
so erwarten wir das beim Mödeltreffen, wenn die,
man hat dafür im Slang den Begriff Power-User, also diejenigen,
die dann zum Beispiel so eine Abfrage machen.
Ich hatte in einem Projekt mal jemand, der ist Unternehmensdaten abfragte.
Ja, und den haben wir dann eine
sehr mächtige Abfragesprache geschrieben
Die am Ende irgendwie zu SQL übersetzt worden ist,
aber er braucht nicht die ganzen SQL-Statements.
Das heißt, wir wollten ihnen auch nicht alle Islamments geben.
Er hat dann die Sprache gehabt, also wir wollten zum Beispiel
mit einem riesen Join, hätte er unsere Produktionsdatenbank angehalten.
Und das wollten wir eben verhindern. Und deswegen haben wir
ihm bestimmte Sachen gegeben, mit denen er kombinieren konnte,
Abfragen kombinieren konnte, ohne sowas zu machen.
Wir wissen alle, von Generator, von Interpretersprachen,
dass sie langsamer sind. Meistens ist das nicht kritisch.
Aber wenn das kritisch ist, sollte man es einfach wissen.
Aber in den meisten Fällen ist das nicht kritisch, weil die Sachen,
die wir hier erzeugen, nicht so mit zeitkritischen Sachen sind.
Und natürlich, der Generator muss viel mehr drin haben,
weil er nämlich noch den Code erzeugt.
Der andere macht ja nur eine Aktion. Und deswegen ist
der Generator meistens vom Codeumfang ein bisschen größer, spielt meistens auch keine Rollen.
Ich habe hier zwei Beispiele genannt. Das eine Beispiel ist eben Hypernate,
was eine XML-Sprache erzeugt, die Mappings zur Laufzeit interpretiert.
Und damit ist das so eine Art DSL. Und das zweite ist,
dass wir in Werkzeugen die Komponenten und Persistenz Permanentmanagement und Kerpesistenz
haben, ganz häufig mit Konfigurationen arbeiten.
Was nehmen, welche Versionen nehmen wir, wann,
wie machen wir das, wie steuern wir den Parameter?
Und diese Parametersätze werden häufig mit Interpretern erzeugt.
Nicht mit Generatoren. Ja, das sind also nur Beispiele.
Am Ende ist der Einsatzbereich von Interpretern fast der gleiche wie der von Generatoren.
Wir haben, wenn wir einen hohen Teil haben,
den wir immer wieder da wiederkehrend ist,
dann würde man so einen Interpreter einsetzen.
Wie gesagt, mit dieser kleinen Einschränkung dass ich das mache,
wenn ich Verhaltensmodelle habe, gibt es das ganz häufiger.
Oder wenn ich schnellere Zykluszeiten brauche, wenn ich nicht erst übersetzen möchte.
Soweit dazu, dann möchte ich noch das ganz links hier vorstellen, Softwareproduktlinie.
Eine Softwareproduktlinie ist etwas, was besteht aus einem gemeinsamen und
einem angepassten Teil. Ich male dazu mal ein Bildchen,
das packe ich jetzt mal direkt hier nach dieser Folie.
Neue Seite, Wehrformat leer. So eine Software-Produktlinie ist
die Basis dafür eine Vielfalt von Produkten darzustellen
Dazu wird ein Produkt aufgespaltet. Heimprodukt sieht dann so aus
, dass es irgendwie eine Basis hat.
Das ist, man kann das auch als Plattform bezeichnen.
Oder jedenfalls hat es Plattformen, ähnliche Dienste wie für Präsistenz.
Am Ende ist es genau das Gleiche,
was wir vorhin in diesem Bild hier hatten.
Ja, dieser Plattformencode. Ja, das brauche ich einmal
. Das brauchen alle. Sowas habe ich hier auch
Das ist dieser Plattform-Code. Ich strichle den mal in der
gleichen Weise, wie wir den hier vorne gestrichelt haben.
Das war hier schwarz. So. So,
und dann gibt es für diese, für einen solche,
um das anzupassen für bestimmt ein großes Portfolio von erweiterbaren Teilen.
Diese erweiterbaren Teile mache ich jetzt mal hier farbig
Ja, und diese Erweiterbarenteile, variable Elemente. Die unterscheiden sich,
je nachdem, welches der Produkte der verschiedenen Produkte ich habe,
gehört das dazu oder gehört das nicht dazu.
Sie kennen so ein Produktportfolio oder können sich das auf jeden Fall vorstellen,
wenn ich irgendwie etwas als kleine Lösung, als mittlere Lösung, als große Lösung habe.
Zum Beispiel so ein Office-Paket. Da gibt es die kleine Lösung,
da gibt es nur eben Textverarbeitung und Tabellenkalkulation die große Lösung,
die gibt es,
da gibt es eben noch Präsentationen und Web-Authoring-Tool und mehr Benutzerverwaltung und Serienbrieffunktion und was ganz viele Sachen,
Datenbankabfragen, Tools, die gehören dann alle mit dazu,
sehr großen Versionen.
Bei der Produktlinie ist es so,
dass ich noch ein sehr viel größere Vielfalt erzeuge,
eben durch die Möglichkeiten, hier aus einer Vielzahl von Dingen auszuwählen und zwar,
dass wir bei der Produktlinie natürlich diese Plattformen haben,
Was ist, beziehungsweise Plattformen?
Und dann haben wir ganz viele solche Variablenteile und aus diesen
Menge der Variablenteile können wir auswählen und das Produkt zusammensetzen.
Das ist also hier die Produktlinie als Beispiel und jetzt Wiederverwendung
DSL, Modelltreffen. Ja, die DSL würde uns
eine Sprache entsprechend an der Sprache etwas ausführen.
Die Produktlinie kann ihn wiederverwenden oder kann ich etwas auswählen,
indem ich sage, ich möchte, dass Teil 1,
3, 5 und 9, ja, und das ist jetzt mein Produkt.
Natürlich lässt sich nicht jedes dieser variablen Elemente,
dies überhaupt der Produktlinik miteinander kombinieren.
Hier gibt es Regeln dafür, welches sich wie kombinieren lässt.
Diese Regeln drückt das Feature-Modell aus, da gehen wir nicht
weiter drauf ein. Auf jeden Fall die Auswahl,
die wir hier haben. Jetzt mache ich es mal rot
Und da kommt es, da kann man durchaus Konfiguration dazu sagen.
Diese Auswahl, die wir treffen, die passiert aufgrund eines Modells.
Und das wäre jetzt das, was wir, das fachliche Modell,
was wir Oder was bei dem MDA hieß das,
Poddel, Product Indefendent Model.
Also diese Anforderungen letztlich, was brauche ich? Das führt,
was woanders wird es übersetzt? Hier führt es zur Auswahl.
Und die Auswahl von und die Konfiguration, das ist das,
was die Produktlinie dann am Ende ein Produkt dann so aussieht.
Und wenn hier etwas anders gefordert wird, haben wir
eine andere Konfiguration, eine andere Auswahl von variablen Teilen.
Und die Menge der Produkte ist am Ende,
oder wir haben hier Regeln, ja, für die Regeln,
für wann, was darf denn hier zusammen miteinander kombiniert werden?
Welche sind denn zulässig, welche nicht? Und diese Regeln
können durchaus auch so ähnlich sein wie eine Grammatik.
Und das könnte jetzt auch hier ein Meta-Modell sein.
Also wir haben dann eine Regelbeschreibungssprache, was kann ich denn wie einsetzen?
Und diese Regelbeschreibungssprache ist, folgt, ist natürlich wieder mit Regeln.
Und das wäre, würden wir hier als Meta-Modell bezeichnen.
So, soweit, dies wäre eben auch noch eine Möglichkeit,
etwas so Wiederverwendbares auf Modellbasis zu erzeugen.
Und nun möchte ich noch zu einem ganz aktuellen Stichwort mal kommen.
Da haben wir auch einen der Vorträge dazu. Low-Code ist jetzt etwas,
was gerade ein bisschen aktuell als neues Stichwort kommt, gehypt wird oder sowas.
Man steht dafür, dass man eine Anwendung entwickelt und ganz wenig nur programmiert.
Das ist ja immer der Traum. Das ist ja das,
was wir bei Skriptsprachen brauchen. Das ist das,
wo wir sagen, eine DSL macht sowas ähnliches und hier nun unter dem Namen Low-Code.
Eigentlich ist es also das,
was schon immer ganz möchte und hier bezeichnet dieses Low-Code eben einen Satz von verschiedenen Werkzeugen,
die zum Beispiel in grafischer Form es erlauben,
dass man eine Applikation, ein Ziel, das Ergebnis,
das gewünschte Programm zum Beispiel per Dreck und Drop zusammensetzt.
Ja, und damit ist es eigentlich nur ein weiterer Ansatz,
dass man nicht so viel programmiert,
dass man nicht so viel von Hand machen muss,
dass der Anwender das tun kann.
Am Ende so ähnlich wie das die DSL auch möchte.
Und am Ende können wir mit dem Low-Code das auch sagen,
ja, so viel anders als Model-Treffen-Development ist das nicht.
Sozusagen das nur nochmal als eines der Schlagworte, ich glaube, zwei Seminarvorträge.
Haben wir zu dem Thema und ihr es ist noch ein
Link angegeben, wo sie einfach mal nachschauen können.
Der Herr Capo sagt hier relativ kurz mal,
stellt die Begriffe so ein bisschen dar,
wie er die definieren würde und stellt die gegenüber.
Damit haben wir so ein bisschen den Bogen geschlagen und zu jedem dieser Teile,
ach so, ich hatte noch nichts gesagt,
wann diese Software-Produktlinien denn eingesetzt werden kann.
Das war ja die Frage 2 hier, ja, Einsatzbereich.
Das wollte ich nicht überschlagen. Gut, dass mir das
noch eingefallen ist. Also, das kann ich vor allen
Dingen dann einsetzen, wenn ich eine relativ große Vielfalt an
Kombinationen habe
Bei der großen Vielfalt an Kombinationen von den vorgefertigten Teilen würde
sich das hier ganz gut lohnen. Und diese Vielfalt wird
dann eben gesteuert durch ein Konfigurator, Konfigurator dieser Elemente der Produktlinie.
So, damit sind wir fast durch. Ich wollte noch zum Abschließen sagen,
dass es eigentlich keine von diesen Technologien,
die ich jetzt hier so im Groben in Gruppen dargestellt habe,
Gib die für alle Zwecke geeignet sind.
Wir haben immer das Ziel, die Effizienz zu steigern,
indem wir wiederholter arbeiten, vermeiden.
Das ist etwas, was Informatiker sowieso ganz gerne machen.
Aber die Entscheidung über das, was ich dort tue,
liegt ganz häufig durch nicht technische Kriterien bestimmt.
Zum einen ist es gut, wenn ich diese Technologie kenne.
Ich werde kaum etwas Neues anfangen,
aber nicht schön Ahnung habe mit DSLs, Ahnung,
habe mit Skriptsprachen Ahnung, habe aber mit Konfiguratoren,
wie sie bei Produktlinien verwendet werden,
dann versuche ich doch diese Technik,
dieses Wissen zu nutzen.
Wie gut sind die Dinger bedienbar
Wieso sind Sie benutzbar für denjenigen, der damit arbeiten muss?
Insbesondere für den fachlichen Experten. Wir hatten eben Power-User bei den Skriptsprachen gesagt,
bei denen er eine DSL geschrieben ist, der wäre auch derjenige,
der Adressate, für den muss das gut bedienbar sein.
Und für die Informatiker, die das Ganze erweitern müssen,
es wird immer neue Möglichkeiten,
werden da gebraucht oder auch diejenigen, die das programmieren müssen,
anhand für diese Protected Regions,
da ist Wartbarkeit ein
ganz großer Punkt
Bugs in solchen Generatoren sind relativ häufig, weil sie halt nicht
so oft eingesetzt werden, wie wenn nicht so wie ein Programm.
Und ich kann die Dinger ja auch kaum testen.
Deswegen brauche ich guten Support beim Hersteller.
Und natürlich liefere ich mich dem auch ein ganzes Stück aus,
indem ich, wenn ich eine große Menge von Softwaresystemen mache,
die mit einem Werkzeug gebaut wird.
Und dann sagt der Hersteller plötzlich, na,
ich verdopple jetzt mal den Preis Polizenz.
Oder ich bin jetzt einfach mal abgetaucht und mache jetzt nichts mehr,
passe jetzt nichts mehr an, keine Bugs mehr beheben,
keine neuen Versionen implementieren.
Dann haben wir, rechte Karten. Deswegen versucht man,
das einzuschränken. Es muss natürlich auch zur Umgebung passen. Ja,
also ich werde nichts machen, was jetzt irgendwie eine ganze Laufzeitumgebung mitbringt,
wenn es am Ende auf einer kleinen Plattform eingeblendet werden.
Und ich muss natürlich immer noch überlegen,
wie hoch ist der Anteil der modellierten Fakten oder vielleicht,
sag ich mal,
der generierten Fakten
Der nicht zu generierenden Softwareteile. Das ist ja damit gemeint,
wenn der Anteil relativ hoch ist, dann lohnt sich das eigentlich nicht,
dann würde man die anderen Teile vielleicht lieber mit dem Template oder irgend sowas machen.
Etwas, was man gut verwenden kann.
Ansonsten überwiegt es es leichter, das manuell zu machen.
So, damit schließen wir diesen Abschnitt ab. Wichtig ist,
dass sie in der Lage sind,
die verschiedene Ansätze voneinander zu unterscheiden,
dass sie in der Lage sind, etwas zu sagen,
wann setze ich denn was ein ein bisschen eine Ahnung haben,
was wir dazu machen können.
Ansonsten nie weiterführen Sachen. Wir haben ein paar Seminarvorträge zu
diesen Themen. Ansonsten werden sie das vermutlich irgendwo mal einsetzen.
Viele Firmen setzen in irgendeiner Form etwas ein zur Effizienzsteigerung
der Programmierung und das sind dann meistens solche Ansätze.
Damit sind wir am Ende.
Vielen Dank