Auch wenn wir mittlerweile die wesentlichsten Messe,
elemente Franzis ML und seine Moderierungen besprochen haben, gibt es weitere Teile,
die erst die Verwendung für die Modellierung großer Systeme erst möglich machen.
Und dazu gehören insbesondere Bezüge. Solche Bezüge hatten wir schon in der Frage zwei,
drei besprochen bei der Verfolgung von Anforderungen,
also die Bezüge zu Blöcken, die das realisieren, die bzw. Testfällen.
Die Frage vier bezieht sich auf Bezug zwischen Struktur und Verhalten,
aber hier auch noch ein Bezug zu Schnittstellen der Umgebung.
Das heißt, zu anderen Modellen
Wir haben hier auf einer Folie diese Frage erst mal,
der Modell sich schon, damit werde ich mich mal einsteigen.
Ich frage, wie geht man mit komplexen Dingen um?
Dass die das mal sehr abstrakte aussichten,
kennen sie als Mittel mit komplexen Modellen umzugehen und diese Sicht
wird hier als durch das Paketsymbol der UNML dargestellt.
Und hier wird in diesem Stereotyp mit diesem kraftlichen Element FewPoint,
wird genauer beschrieben, was ist denn das Modell?
Das nimmt direkten Bezug auf das,
was wir in dieser Lehrveranstaltung immer wieder wiederholen, gebetsmütigenbildenartig,
sie sich glauben, ist das Ziel, das der Tätigkeit ist,
man sich glauben, dass das Zweck der Zweck des Modells ist,
das ist genau hier drin.
Das ist das Concernen Purpose. Was ist das? Und
dann, was brauchen wir wirklich, um das darzustellen?
Das würde jetzt hier, wie wird die Modell sich da stärken?
Na gut, das ist so ungefähr, aber welche Modellierungsspaß
sollte das denn sein? Welchen Ausschnitt brauchen wir,
diese Entscheidung wird jetzt hier nicht mit abgedeckt,
aber so ein bisschen durch den Stakeholder,
wer interessiert sich für was,
zum Beispiel für die Detailtiefe
Ich habe jetzt hier für kein Beispiel mitgebracht,
aber ich möchte aus dem Flugzeugbau hier mal Themengebiete nennen, die man so sagen kann.
Also es gibt, ich trübe einen Link in die Materialien mit rein,
die nur die Kielerung eines Buches über Luftfahrt,
der über das Fahrzeugentwurf, der uns zeigt, welche Teilgebiete sind.
Und das ergebe ich mal hier ein. Beispiele für Teilaufgaben,
jeweils eigenen Sichten, und das beim Flugzeugbau wäre das,
ich nehme niemanden die englische Begriffe,
wie sie die in der Übersicht der Gliederung dieses Buches erfinden,
wäre das zum Beispiel die Gestaltung des Flügels,
Herwin Design wohl dazugehört, wie ist die Aerodynamik,
wie ist das Gewicht, wie ist die Stabilität,
Fragen der Ausdauer der Reparaturfähigkeit spielen da ebenfalls eine Rolle.
Dann das Antriebssystem,
populischen Systemdesign
Wo die Leistung halt, das wird andersrum beschrieben,
die sammeln, wo die Leistungsfähigkeit genauso eine Rolle spielt,
wie der Energieverbrauch.
Dann die Leindeklappen. Ein separater Teil des Flügels.
Aber für andere Fluggeschwindigkeiten gedacht und natürlich völlig andere Strömungsverhältnisse und
dann die Energieversorgung, die Treibstoffversorgung.
Design,
das schreibt noch besser
Dann gibt es solche Fragen wie Gewicht. So,
die Freude des Gewichts spielt beim Flugzeug bei allen Teilen,
die dort mitfliegen, eine große Rolle in der Planung.
Und da kommt auch alles zusammen von allen Teildisziplinen. Also das ist nur so ein Beispiel zu haben,
dafür für jedes dieser Sichten könnte ich hier,
für jedes dieser Teilaufgaben könnte ich hier eine Sicht einführen und dann ist es hilfreich zu sagen,
für wen ist denn diese Sicht interessant und was gehört in das Paket beziehungsweise Diagramme dieser Sicht zuordnen?
Das ist eine Frage von Zuordnung und das brauche ich natürlich nur bei komplexen Dingen.
Hier für unser Beispiel hilft uns das denn,
wenn es ein neuer Flugzeugtyp geben sollte, eine Abwartung eines bisherigen ist,
okay, der Flügel bleibt im Prinzip klein,
gleich wird nur ein bisschen größer, proportionales Flügte,
das Antriebssystem wird nur ein bisschen größer, ja,
aber vielleicht werden die Landeklappen ganz verändert,
weil man vielleicht auf einer rauen Pistearbeit landen will oder irgend sowas.
Soweit dieses Modellelement sichten
Weitere Zuordnungen sind durch Elocations gegeben. Diese Elocations,
das hatten wir schon bei den Pfeilen, die es für zu, für Einforderungen gibt.
Wir hatten, ich gehe nochmal zurück zu dem Teil,
den wir schon gesehen haben, zu den Anforderungen.
Da gab es ja hier so eine ganze Reihe von Zuordnungen für die Verfeinerung,
für die Erfüllung einer Anforderung oder für die Überprüfung in der Anforderung.
Und das sind jeweils Bezüge von Anforderungen zu etwas anderem,
also Anforderungen zu dem Blogbaustein,
die Richtung ist jetzt so angegeben wegen der Bezeichnung,
also der erfüllt das oder der prüft das,
aber eigentlich von der Reihenfolge der Arbeit habe ich zuerst die Anforderungen und später die Lösung,
zuerst die Anführung, später den Test fallen.
Gehen wir zurück zu den Zuordnungen hier zwischen Blöcken, da haben wir die ganz genauso.
Hier gibt es zum Beispiel die Zuordnung von einem physikalischen Systembaustein,
also etwas, was sie anfassen können,
was wirklich eingebaut wird, was wirklich eine Instanz ist,
zu einem logischen Systembaustein,
logisch heißt die in dem Fall eine Aufgabe.
Ja, schreiben wir uns mit dran. Diese Aufgabe stammt aus der Spezifikation,
ja, und der realisiert der physikalische Baustein,
der realisiert die Lösung der Aufgabe.
Und das ist dann die technische Lösung. Also,
wenn man das System, also wie es betrachtet,
ist das der Lösungsbereich. Das ist eine Form der Zuweisung,
die wir hier mit diesem Fall machen kann.
Weitere Zuweisungen sind dann welche, die ich zum Beispiel im Aktivitätsdiagramm habe.
Also sie kennen diese Diagrammform, das ist das Aktivitätsdiagramm.
Und diese Dinger hießen im Swim, Swim Lanes im Chargon.
Offiziell heißen die Verantwortungsbereiche. Und wer ist denn hier verantwortlich?
In der UML hatten wir ganz häufig für die Verantwortungsbereiche hier irgendwie Akteure.
Das macht der Kassierer, das macht der Student oder was auch immer.
Hier bei, wir können das gleiche Diagramm verwenden,
zu sagen, wie arbeiten die Bausteine zusammen.
Zum Beispiel der physikalische Baustein, der hier zugeordnet ist,
der macht die Aktivation 1 und jeder physikalische Baustein dazu und das macht die Aktion 2.
Das wäre zum Beispiel, das sind strukturelle Bausteine,
die sind im Struktur- oder im Blockdiagramm zum Beispiel.
Und das kann sie Diagramm hier, ist ein Verhaltenszieherkram.
Und auf diese Weise kann ich eine Zuordnung zwischen Verhalten und Struktur machen.
Verhalten und Struktur, das war also eine Frage dieser Wiederholungsfragen.
Wir gehen mal kurz zurück. Also das war
die Frage 4 hier. Zwischen Verhalten und technischer Plattform.
Das wurde dementsprechend in dem Fall im Verhalten zur Struktur
wieder zurück.
Wo waren wir
Genau. So, dann ein weiterer Punkt,
wo wir Zuordnungen haben,
das spricht wieder dieser Frage 4. Wir haben hier zum Beispiel ein Aktivitätstier,
kamen Sie erkennen das am Stadtknoten und das hier auf Aktionen drinsteht,
eine Aktion, noch eine Aktion, noch eine Aktion.
Sie wissen aus der UML, wenn hier zwischendurch ein Kasten
ist, da ist das ein Objektfluss.
Dieser Kasten sagt, was passiert da, was für Datenmänner übertragen.
Datenfluss würde man als Entwickler vielleicht wahrscheinlicher sagen,
als Objektfluss, ein Objektfluss ist dieser Bezeichnung,
also hier habe ich die Objektknoten und der soll sich sehr übertragen,
dass schon das Datum, zum Beispiel die Daten sind im Systembaustein zugeordnet.
Und die Aktion ist dann auch ein Systemzustand beispielsweise im Prozessor zugeordnet.
Vielleicht passiert das hier im Grafikprozessor oder in irgendeinem Steuercomputer oder was auch immer.
Hier sogar eine Zuordnung für einen Datenfluss. Sie sehen wieder hier,
dass es bei diesem Fall sich nicht um einen Steuerfluss handelt. Das ist ein Steuerfluss,
aber das ist ein Datenfluss, weil wir am Anfang,
wenn am Ende diese Kästchen haben,
vielleicht schauen Sie doch mal nach, bei der UML,
beim Aktivitätsjahr kam, da hat man gesagt, ja,
wenn hier ein Kess,
ein großer Kasten oder Anfang und Ende ein kleines Kästchen dabei ist,
jetzt für die Pops, dann ist das jeweils Datenfluss.
Und hier ist der Datenfluss eben im Connector zugeordnet. Auch hier,
dadurch, dass hier drin diese Eloquette-Tool-Elemente vorkommen,
ist das eine Zuordnung zum System, vom Verhalten zum System wird,
das Diagramm stellt das Verhalten dar,
ein Aktivitätstier kam,
stellt das Verhalten dar und wir weisen hier,
das Verhalten in Teilen des Verhaltens irgendwelchen Systembausteinen oder Interfaces
Weitere Zuordnungen kann es geben, indem man tabellarische Darstellungen nimmt,
indem man zum Beispiel sagt, das und das,
dieser Wert ist in dem Parameter drin.
Oder dieses Signal ist in dieser Leitung trippen.
Oder dieser Datenstrom ist ja dort in der hohen Konstruktion drin.
Also diese Zuordnungen gibt es ganz genauso. Okay,
ein weiterer Punkt, ich hatte eingangs beim Bezug zur UML Zusicherungen.
Zusicherungen sind Sachen, sind logische Ausdrücke, die immer wahr sind.
Wenn sie nicht wahr sind, ist irgendwas fehlgeschlagen.
Ich kann zugestützte Zusicherungen auch nutzen, um auszudrücken,
dass bestimmte Bedingungen zuverlässig eingehalten werden oder eingehalten werden müssen. Dafür gibt es einen Zusicherungsstein der Parameter ausdrückt,
Parameter beschreibt und Bezüge zwischen Parametern beschreibt,
die Bezüge können sein Bezüge zwischen Werten, irgendwelche Formalien,
also Formeln oder auch nur,
dass man nur kritische Eigenschaften dort explizit nennt,
dass das System, das Modell klar macht,
zum Beispiel mein Flugzeug,
die Abfluggeschwindigkeit ist ganz entscheidend und es gibt eine minimale Landegeschwindigkeit,
wenn es drunter ist,
dann haben wir ja keine Strömung mehr und
das Flugzeug wird nicht mehr getragen durch die Irrdüner
Diese Zusicherungsbausteine sind erstmal auch, solche Elemente mit Plästchen und Linien,
aber hier kann ich die Konstruenz reinschreiben, beziehungsweise die Parameter.
Also die Konstruenzen sind logische Verknüpfungen, logische Regeln, wenn sie so wollen,
und die paar Meter sind Werte, die in diesen Regeln drin vorkommen.
Dass die Darstellung, die grafische Darstellung, könnte so aussehen,
dass wir hier solche Ports fahren haben für die Werte und die Werte werden den Dingenden zugeordnet.
So, was ich noch eingeben möchte, sind,
dass es auch Pakete gibt, Ich hatte schon darauf hingewiesen,
auf dieses Zerlegungsding, was ja eigentlich das Gleiche ist,
das könnte, mir könnte man das auch ganz genauso so machen,
dass man hier solche Teile ganzes Beziehungen dann macht,
ja, das würde auch funktionieren.
Das ist das, diese Darstellung hier mit den Rompen,
das wird eher in der UNL gemacht und das ist eher so SSML-mäßig,
da haben sich die Macher, aus meiner Sicht,
das ist nicht gut, überlebt.
So, damit haben wir diese Zuordnungen besprochen,
die sind hier, wie halte ich für sehr wichtig,
weil man immer, vielleicht sollte ich das noch dazu sagen,
zu diesen Sichten,
wo waren die
Hier waren die Sichten, ja, wenn ich viele verschiedene Sichten habe,
gibt es keine Gesamt an sich mehr, weil das Ganze zu komplex ist.
Auch einer Müllkapete an der Wand reicht nicht, um das ganze Modell abzustellen.
Und deswegen brauche ich diese Aufteilung. Und damit die Aufteilung aber wieder Verständlichkeit,
brauche ich diese Zuordnungen, die wir jetzt in verschiedenen Darstellungen hier hatten,
hier grafisch oder eins vorher durch Zwischenmodelle Menschen so.
Oder auch, dass ich gesagt habe, in Tabellen steckt das drin.
So, mit der BRK-Übersicht war gesagt, nein,
das war es noch nicht, in der DRK-Übersicht war gesagt,
ja, das Aktivitätsdiagramm ist so ähnlich.
Tatsächlich haben wir hier den Stadtkloten, wir haben den Endkloten,
aber wir haben zusätzlich Ströme, wir haben Zeitsignale, Signalenmpfang.
Diese Elemente, die hier da stehen, sind mehr oder weniger,
als wir sie zum Überblick, da meine ich,
das müssen sie nicht auswendig, was hier drinsteht,
es ist im Prinzip möglich, alles Mögliche darzustellen.
Also wir, was sie kennen von der UML,
wisst ihr, war ja das Parallelität,
also hier ist aufs Gitten, Synchronisation,
es geht erst gleich in beide Aktionen sind,
aber es gibt ja noch viele andere Sachen,
die auch
eine Rolle spielen
Indem ich sage, hier in diesem Datenflussstrom oder was,
packe ich hier so eine Referenz rein.
Oder ich gebe hier noch an, dass es eine Verfeilerung gibt.
Das hat man, das ist ein Öffner vom BBMN übernahmen.
So Parameter kann ich hiermit gleich mit angeben. Also es gibt ganz viele Möglichkeiten,
die versuchen sie, sich für einen Bedarfsfall,
wenn sie mit Systemwelt zu tun haben,
mit der Literatur zu beschäftigen, versuchen sie,
die Elemente zu benutzen, möglichst viel in die grafischen Elemente packen.
Denn hier kann ich viele Informationen angeben,
die ich sonst textuell beschreiben müsste
Ihr kennt sie immer noch, dass er sie liegen,
denn ein Modell und sind Änderungen über alles hinweg.
Zugänglich. Ich kann Aktivitäten verfeinern, das ist im Aktivitätsdiagramm auch möglich.
Die Verfeinerung kann so erfolgen, dass wir hier ein Zerlegung haben, die Konfositionen.
Sie wissen, wir ausgemalte Raumbusse ist in der Uni. Die Komposition,
jetzt hat es doch eine Sekunde gedauert,
also wir hatten ja Aggregationen und Kompositionen als die Zerlegung und hier
kann ich die Zerlegung einer Aktivität in eine andere Aktivität mit Diagrammelementen darstellen,
dass wir wiederum eine Zuordnung zu einem Systembaustein, der für diese Aktivität entscheidend ist.
So, soweit zu den weiteren Elementen und ganz abschließend als Letztes möchte ich noch darauf hinweisen,
dass die Utsus-NL 2-0,
auch wenn sie im Moment noch nicht ganz fertig ist,
wenn es noch Veränderungen gibt,
dass sie ein bisschen eine größere Veränderung bringen wird,
was die Susanne älter trifft, sind sie einfach auch vorbereitet,
dass es die in Kürze geben wird.
Man kann erwarten, dass es deutliche Unterschiede zu UML gibt,
Bisher war, bisher war das, hat sich das ja sehr stark eingekäglichen.
Es wird ein besonderes Augenmerk geben auf Schnittstellen, Schnittstellen, insbesondere zwischen Werkzeugen.
Dass man Modelle einsetzen kann für verschiedene Werkzeuge. Das Systems Engineering ist geprägt von,
oder das Finte, Anmeldungen in Industrien mit ganz viel getrennten Auftragnehmern,
also in der Automobilindustrie ist das genauso der Fall,
wie ein Flugzeugbau und in anderen Bereichen,
dass man ein separate Unternehmen hat, die separat agieren,
aber die Modelle miteinander austauschen können.
Und da muss es natürlich möglich sein,
herstell mal übergreifend auszutauschen
Und für diesen Herstellerübergang das Werkzeugastaustausch gibt es mit dem Modell basiert.
Es ist ein API and Services,
ein Teil des Modells der Beschreibung von SystemL 2.0. Als Überschrift,
als Übersichtsmöglichkeit gebe ich immer einen Link an,
der von Kim Vikings zu seinem Block und zur Seitenseiten führt,
wo er verschiedene Informationen dazu bereitstellt nach dem aktuellen Stand.
Tim Vikings ist eine der Autoren des Buchs,
das wir für diese Mehrfaltstellung benutzen.
Damit nochmal als abschließend, wie gesagt,
bleiben Sie aufmerksam
Da wird noch Fotografie, das Interessantes passieren und versuchen sie,
Beispiele selbst zu finden, die wir hier verwenden können.
Wie gesagt, Systems Engineering ist etwas für große Systeme,
wo ich wirklich den Augenblick nicht behalten kann.
Und deswegen braucht man Arbeitsteilung. Deswegen braucht man Modelle.
Und deswegen braucht man auf die vielen Änderungen Varianten auch Toolunterstützung.
Und deswegen ist System Eltern doch eine sehr mögliche Sprache mit
vielen Möglichkeiten für formale Spezifikationen für formale Angaben