In diesem Kapitel beschäftigen wir uns mit der Modellierungssprache, SSML,
die eine weitere Ausdrucksmöglichkeit für die Modelle, für die Modellbasierte Entwicklung bringt.
Im ersten Teil geht es uns um die Einordnung und um die Anforderungen.
Das werden die Fragen 1 und 2 sein. Auf dieser Literaturhinweise sehen Sie ganz unten,
vor allen Dingen, nein, das sollte nur gezeichnet sein,
auf der untersten Stelle sehen Sie den Link zur Spezifikation,
das ist ein relativ umfangreiches Dokument,
das haben wir ja auch in einer der Übungsaufgaben.
Dann gibt es noch Tutorials und diverse Bücher,
wobei sich nicht alle auf die letzte Version beziehen.
Man muss dazu sagen, die Versionsunterschiede sind nicht so groß.
Vielleicht erstmal starten wir Mitte einer Einordnung. SCML ist entwickelt
worden von Leuten, die ihr Arbeitsgebiet als Systems Engineering bezeichnen.
Systems Engineering, dabei geht es um die Entwicklung.
Es ist erstmal dem Wortschnitt schon Ingenieurdisziplin.
Es geht darum, komplexe Systeme zu entwickeln
Ein gutes Beispiel ist vielleicht etwas aus der Luftfahrt.
Sie haben vielleicht vor einigen Jahren gehört,
dass es bei Airbus Probleme mit den Kabelbäumen gab,
in einem, wo man mit Modellen gut helfen kann.
Warum braucht man da Modelle? Es arbeiten bei
so einem Projekt wie dem Bau eines Flugzeugs,
bei einem das Passagierflugzeugs zum Beispiel, sehr viele Menschen zusammen.
Sehr viele Spezialisten, die jeweils einen kleinen Bereich betrachten,
wie zum Beispiel die Luftversorgung in der Kabine,
die Steuerung der Triebwerke, die Energieversorgung an Bord,
Dinifikation mit Zusammenhang, mit dem Wetter.
All solche Sachen sind jeweils Teilgebiete und diese Teilgebiete
müssen aufeinander abgestimmt werden. Wir haben sehr viele Informationen.
Das heißt, es ist auf jeden Fall zu viel.
Es ist ein Mensch, die erfassen kann. Und wir
haben Änderungen. Natürlich kann ich das Ganze auf Papier beschreiben.
Ja, also ich könnte auf einem Papier beschreiben,
was das Flugzeug können soll. Wie ist es aufgebaut?
Wie sind die verschiedenen Teile gebaut? Nur dann müssten wir
jedes Mal bei jeder kleinen Änderung immer schauen,
was denn mit wem zusammenhängt.
Sie erinnern sich an die Modelle, auf die verschiedenen Ebenen,
Kategorien von Werkzeugen
Gibt es das Werkzeug, wo das Modell alles zentralisiert ist.
Das würde uns sehr helfen, die Ausbreitung von Änderungen
zu überschauen, zu prüfen, zu bewerten.
Nun geht es da bei dem Flugzeug nicht um Software.
Deswegen dieser Begriff System. Es geht um komplexe Systeme. Diese Leute,
die das entwickelt haben, wir kommen gleich zu den Kreisen,
die da den Einfluss draufgenommen haben,
wollten das in irgendeiner Form etablieren, wollten das populär machen.
Und da liegt es ja nahe,
sich an etwas dran zu hängen, was schon populär ist.
Deswegen hat man sich entschieden, das ist meine ganz persönliche Interpretation dieser Geschichte.
Man hat es für vorteilhaft gehalten, das als Erweiterung der
UML einzuführen. Weil für UML gibt es schön Werkzeuge,
UML hat eine Community, UML ist als Standard zu diesem Zeitpunkt,
als es eingeführt wurde als Standard etabliert.
Heute ist es, es wurde standardisiert von der OMG,
der Object Management Group, die gleiche Standardisierungsorganisation,
die auch die UML standardisiert hat.
Die letzte Version, die zurzeit gültig ist, ist die Version 1.6.
Man muss gleich dazu sagen, Es gibt eine Version 2
-0, die ziemlich kurz vor der Fertigstellung ist.
Das bedeutet, es gibt noch Änderungen. Deswegen ist die
heute in dieser Lehrveranstaltung auch noch nicht aufgenommen.
Wir haben auf der letzten Folie ein paar Hinweise dazu.
Wir werden dazu kommen, dass SCML verschiedene Beschreibungsebenen zulässt.
Wir haben bis jetzt für Softwareentwicklung davon gesprochen,
dass wir Problembereich und Lösungsbereich haben.
Hier teilt man noch weitere Ebenen, die so ein bisschen auch naheliegen,
für welche Sichten diese Sprachen geeignet sind.
So haben wir zunächst die Operationale Ebene,
operationale Ebene meint die Benutzung
Die Einbettung mit anderen Systemen, Einbettung in Umgebung.
Dazu gehören eben all die Dinge, die hier drunter stehen,
Funktionen, Teilfunktionen spielen dabei eine Rolle.
Das heißt, das, was in der Anforderungsbeschreibung steht.
Auch die nicht funktionalen Ziele spielen eine wichtige Rolle.
Ich nehme hier, gebe ich als Beispiel, Zeitverhalten,
Zuverlässigkeit, Sicherheit, einen vielen Domänen sind das
die wichtigsten Qualitätsziele
Aber es gibt auch strukturelle Informationen, die mit der Umgebung zusammenhängen,
zum Beispiel, wie sind die Daten organisiert,
die diesen Systemzustand und die Eigenschaften beschreiben.
Wie ist das Ganze organisiert? Das heißt, aufgeteilt,
wie sind Verantwortlichkeiten zugewiesen? Wie arbeiten Menschen damit? Und
zwar wird da nicht der einzelne Mensch betrachtet, sondern die Rollen werden dann betrachtet.
Für Abläufe ist es sinnvoll, das auch zu verallgemeinern,
nicht der einzelne Ablauf, sondern der Prozess, das Szenario.
Häufig sind Geschäftsprozesse hier, das Ausdrucksmittel,
was man wählt und dafür gibt es auch Regeln,
die dann im betriebswirtschaftlichen Bereich häufig Geschäftsregeln heißen,
woanders würden sie vielleicht anders bezeichnet. Das ist die Ebene,
wo wir auch von das System in seiner Einbettung betrachten,
wo wir betrachten, was wie das System arbeitet.
Deswegen habe ich hier Benutzung hingeschrieben als Erläuterung dieses Begriffs,
was mit operational bezeichnet ist, die Operation.
Da nähe ich die nächste Ebene, die wir mit der SystemL beschreiben können,
ist die Systemebene. Dabei wird das System selbst betrachtet,
es wird betrachtet, wie sieht die technische Lösung aus,
wie sieht sieht seine Struktur aus,
das ist also das Statische, wie ist das Verhalten,
das ist das Dynamische, wie ist die Realisierung,
das heißt, wie sind die technischen Gegebenheiten, die Parameter, all sowas.
Und natürlich ganz besonders, wie sind Ressourcen eingesetzt,
Ressourcen braucht man für Ausfallsicherheit, indem man sie parallel anbietet als Redundanz,
die braucht man für Performance, damit man die Leistungsanforderungen befriedigen kann.
Und man kann noch eine Ebene tiefer gehen mit der SSML,
nämlich dieses Verhalten, die Eigenschaften den Aufbau,
die wirkungsweise einzelner Komponenten zu betrachten,
Das könnte zum Beispiel sich um die technische Plattform handeln,
aus der das System aufgebaut ist, mit den Teilen,
auf denen das System besteht, wiederum Struktur und Verhalten,
Ressourcen hier nochmal aufgeführt.
Diese, ich sagte schon, dass Süß-ML mit Bezug zur
UML entwickelt worden ist. Meine These eben,
man wollte sich davon darin so ein bisschen,
die es schaffen, dass man Akzeptanz gewinnt.
Eine Norm, ein Standort, eine Programmiersprache,
eine Modellierungssprache sind nur dann erfolgreich,
wenn sie
breit akzeptiert werden
Nämlich diese Akzeptanz führt dazu, dass das überhaupt ein Markt ist,
zum Beispiel für den Tools entwickelt werden. Man hat damit angefangen,
dass man gesagt hat, okay, UML hat Erweiterungsmöglichkeiten,
sie alle kennen mittlerweile die Profile von UML und man hat deswegen
Süßermänner als Profil der UML als Prinzipprofil von UML2 definiert.
Es ist eine Untermenge, weil ich gesamte UML betroffen ist.
Man kann aber sagen, die liebe ich durch andere UML-Teile ergänzen.
Gleichzeitig hat man die Möglichkeit geschaffen und das ist eine weitere Ähnlichkeit zur ML,
dass man XMI als Metadatenformat, Austauschformat, das Dateiformat benutzt,
um Dateienmodelle abzuspeichern, um Modelle zwischen verschiedenen Werkzeugen auszutauschen.
SMI steht für XML Metadata, Interchange,
Metadata sind die Daten, Metadatin, Sendatin über Datin.
Das heißt, das ist das Beschreibungsformat der Modellierungssprache.
Wenn Sie so wollen, Syntax und Semantik steckt da drin.
Ein weiterer Parallele zu UML ist, das ist aber als
Zeitversion 1.6, dass es möglich ist, OCL einzubetten.
OCL, die Object Constraint Lang mit Steve,
wir sind dieser Lehrveranstaltung auch nochmal besprechen werden,
betrachtet logische Bedingungen, logische Zusammenhänge in Form von Zusicherungen.
Diese Zusicherungen sind genauso wie in der UML natürlich auch als natürliche sprachliche Ausdrücke möglich,
aber eben dieses OCL, von dem wir noch nicht viel wissen,
nur als wir schon mal als genannt, als Querbezug,
auch etwas, was mit UML ähnlich ist.
Ja, entwickelt wurde das Ganze, eigentlich muss man sagen,
von diesem International Council on Systems Engineering. Das ist eine Ingenieurorganisation,
die sich auf die Fahnen geschrieben hat, Arbeitsweise,
das Herangehen und damit auch Modellierungen und Werkzeuge in dem Gebiet Systems Engineering zu verbessern.
Und man hat sich dazu die Object Management Group gesucht,
die diesen Standardisierungsprozess vorantreibt und zusätzlich,
weil der Datenaustausch auf Modellebene zwischen Werkzeugen so entscheidend ist,
besonders in diesem Gebiet gibt es hier noch eine Arbeitsgruppe,
AP233, die das Datenaustauschformat unterstützt,
entwickelt.
Soviel zur Einordnung, zum Bezug zur OML.
Das ist gleichzeitig auch die erste Frage,
wie steht das Ganze zueinander in Bezug
Und dieser Bezug besteht darin vor allen Dingen, dass die UML,
das ist ein Inhalt als Profil der UML definiert ist.
Profil war ja die Zusammenfassung von Verfeinerungen, also da ging
es um Stereotype und weitere Anwaltmöglichkeiten, OML zu verfeinern.
Das ist also hier gemacht worden. Die Erweiterungen bestehen darin,
also es ist mehr als die UML, so vieles,
klar, die wesentlichste Erweiterung sind aus meiner Meinung nach die Blöcke,
die werden wir in dieser Veranstaltung auch noch mit ein paar Bildern sehen und zwei Diagrammtypen beschäftigen sich damit.
Zusätzlich kann ich Flüsse darstellen. Damit meinen wir aber nicht
den Fluss, auf den man mit im Boot fahren kann,
sondern Datenflüsse, Energieflüsse, Stoffströme.
Auch selbst sowas wie ein Audiofluss von Audiodaten könnte ich damit darstellen.
Das spielt in Systemen eine viel größere Rolle bei Software nur gering.
Das ist jedenfalls hier richtig darstellbar. Zusätzlich kann ich
Eigenschaften von Werten darstellen, das brauche ich insbesondere,
wenn ich dann mit mir über Parameter und Datensätze spreche
Ich kann Allokationen durchführen, Zuordnungen zu Weisungen.
Das brauche ich immer dann, wenn ich sage,
zum Beispiel dieses Kabel ist, an dem trägt dieses Signal.
Dieses Kabel ist an dem und dem Anschluss angesteckt oder angeschlossen.
Der und der Rechenprozess läuft auf der Maschine.
Oder diese Maschine ist für die Aufgabe zuständig. All solche werden
dazu noch kommen. Diese Elocations spielen eine wichtige Rolle und
diese Rolle wird zunehmend mit der Weiterentwicklung von SSML immer wichtiger.
Außerdem haben wir die Möglichkeit, Parameterisierung vorzunehmen und auch
kontinuierliche Abläufe darzustellen
Bei Daten habe ich immer diskrete Abläufe. Das heißt,
ich habe einen genauen Unterschied zu dem Zeitpunkt und zu dem Zeitpunkt und zu dem Zeitpunkt.
Und ein kontinuierlicher Ablauf bedeutet, es gibt einen genauen Fluss,
zum Beispiel eine Temperatur in einem Raum.
Die hat nicht nur vor 31 und 11.32 eine Temperatur,
sondern die hat ständig eine Temperatur. Und diese ständigen Verläufe,
das kann ich halt hiermit darstellen, das brauche ich bei Signalen,
das brauche ich bei Medien, aber auch bei Strömen.
Soweit, das sind die einzelnen Erweiterungen und dieses nächste Bild
zeigt uns so ein bisschen die Einordnung im Zusammenhang mit
so einem Bild
Der Diagramme. Wir haben so ein ähnliches Bild bei der UML schon mal gesehen.
Hier ist es ein Bild wie Süß-ML, sich von UML unterscheidet.
Zunächst haben wir, müssen wir erst mal sagen,
bei UML haben wir Verhaltensdiagramme und Strukturdiagramme.
Bei Süß-ML haben wir zusätzlich noch als separate Gruppe das Anforderungsdiagramm.
Das ist weder das eine noch das andere, sondern ein separat ganz neues Diagramm.
Ganz neu sind die blauen Dinge. Hier sehen wir schon,
dass Parameterdiagramm gibt es hier auch. Das ist das,
wo wir in dieser Lehrveranstaltung noch am wenigsten eingehen werden.
Aber es spielt auch eine Rolle. Das Aktivitätsdiagramm ist stark oder etwas
verändert wurden gegenüber der UML. Und dann gibt es die beiden Blog,
die ja kramme, Blog Definition Diregram und Internal Blog Diregram,
die beide Abwandlungen des Klassendiagramms sind und als solche eigentlich neue Diagramme,
aber man kann auch sagen, okay, ist stark verändert sind.
Wir starten jetzt mit den Anforderungsdiagrammen, aber vorher möchte ich kurz
nur mal in einen ersten Blick geben, was man meint mit Profil.
Also sie kennen diese beiden spitzen Klammern hier,
Die heißen Stereotyp, ist eine Erweiterungsmöglichkeit der UML.
Wir haben dieses Stereotyp in dieser textuellen Form mit den spitzen Klammern.
Wir haben es aber auch in grafischer Form. Und diese
grafische Form ist zum Beispiel diese 3D-Darstellung, das heißt,
aus einem Rechteck wird ein dreidimensionaler Körper in Quader.
Und dieser Quarter steht in der UML für Device. Der spürt,
dieser Quarter wird in SüßemL ganz viel für Blöcke benutzt.
Und hier gibt es noch verschiedene Symbole, die ich dort einpacken kann.
Wir haben hier Flüsse, wir haben hier normalerweise normale Beziehungen,
den Benutzer, das kennen wir schon als grafisches Stereotyp, er zieht sich dir zusätzlich das textuelle Stereotyp-User.
Nochmal drunter, oder Ektor gibt es auch noch. Ja,
soviel erstmal als Einblick, dass es würde zum Beispiel entsprechen,
dem dieser Ebene operationale Ebene,
ja, wo wir also die Einbettung in das,
der Indie-Struktur des Gesamtsystems sehen, also vielleicht eher so was mit Organisationen,
welche Teile des Systems gibt es, welche Funktionen,
welche Teilfunktionen sehen wir hier,
das ist der Blick auf das System von außen,
also hier ist das System, es ist dargestellt als Blackbox,
sehen nicht hinein, aber wir sehen die Einbindung mit allen anderen Sachen,
das wäre diese operationale Ebene.
Als kleine Aufgabe möchte ich Ihnen mitgeben, in diesem Video,
sich zu überlegen, für welches der gezeigten Diagramme,
für welche Ebene geeignet ist.
Typischerweise ist das für mehrere Ebenen geeignet, aber ich möchte
das dann mit Ihnen diskutieren in der Frage Antwort-Session.
Wir machen jetzt mal, starten mit dem Antwortungsdiagramm.
Anforderungen spielen eine ganz wichtige Rolle für die Systementwicklung,
wie für alles andere auch, weil wenn ich die Anforderungen nicht richtig verstehe,
dann baue ich das falsche System,
selbst wenn ich alles richtig mache
Für die Anforderungen wird hier das grafische Element recht eck verwendet.
Ich kann das aufteilen, dieses rechte ist normalerweise in der UML ein Kasten.
Eine Klasse, sorry. Aber man nimmt hier das Stereotyp
Requirement hinzu mit den doppelten Spitzenklammern, um das zu kennzeichnen.
Und damit ist es eine Anforderung. Diese Anforderung kann geteilt werden,
und zwar hier einfach geteilt werden,
indem man hier unten noch Daten reingibt,
zum Beispiel eine ID, einen Text oder noch weitere Informationen.
Man lehnt sich daran an,
dass Anforderungen häufig sehr wenig formalisiert sind,
dass sich natürliche Sprache spielt,
eine wichtige Rolle
Aber sowas wie die IDs, die hat man dann traditionell verwendet,
um Abdeckungs- und die Vollständigkeit der Abdeckung zu prüfen.
So, es gibt jetzt eine ganze Reihe von,
also zunächst erstmal diese Kastenformen, die müssen wir uns merken,
dass Anforderungs, die Requirement als Stereotyp, müssen wir uns merken.
Und es gibt ein paar Beziehungen dazu. Wir haben die Gestrichelte,
die gestrichelte Linie, die kennen Sie auf jeden Fall noch
von UML, gestrichelte Linie bedeutet Abhängigkeit.
Die gestrichelte Linie allein sagt nicht so sehr viel,
sagt nur, Abhängigkeit, meine persönliche Übersetzung von Abhängigkeit ist,
wenn das eine geändert werden muss,
muss das andere auch geändert werden, ja.
Und hier hat man durch den Stereotyp Copy noch ein bisschen genauer gesagt,
was hier passiert, nämlich, dass hier Anforderungen kopiert werden.
Und das heißt, wenn sich das ändert,
muss die Kopie hier auch geändert werden.
Das ist das Wesen einer Abhängigkeit. Hier haben wir weitere Sachen.
Hier gibt es zum Beispiel die Zerlegung. Nun können wir uns sagen,
Zerlegung, das ist Dekomposition, Teil von,
kennen wir doch schon, Teil von, das wäre ja,
das wäre ja dieses, diese Aggregationsbeziehung,
die Raute,
die wir da haben
Und tatsächlich ist das, finde ich, das persönlich ein bisschen unglücklich,
in den Klassendiagrammen der UML haben wir diese Raute für die Dekomposition.
Und hier haben wir für die Dekomposition dieses Plus mit dem Kreis.
Ich kann es leider nicht ändern, es ist meiner Meinung
nach unglücklich, weil die Komposition gibt es ja schon.
Gut, also jedenfalls ist das, die Dekomposition von Anforderungen
im Anforderungstier kam. Von den verschiedenen Beziehungen,
die man auf Basis der Abhängigkeit genauer nimmt,
gibt es zum Beispiel dieses DeRive,
eine Abhängigkeit wird aus einer Anforderung wird aus einem anderen ein Verdruck abgeleitet.
Das bedeutet also, wenn dort gefordert zum Beispiel,
ich brauche eine hohe Zuverlässigkeit und daraus wird abgeleitet,
das und das ist jetzt redundant.
Ja, das wäre also eine abgeleitete Anforderung. Man kann das
einerseits so machen, dass man zwei Anforderungen miteinander verbindet.
Das geht aber nur, wenn ich sie im gleichen Diagramm habe.
Wenn ich sie nicht im gleichen Diagramm habe,
brauche ich einen Anker, die Referenz irgendwo anders hin.
Und das kann ich zum Beispiel so machen,
indem ich so ein Notiz verwende und diese Notiz mit Deo Reif bezeichne.
Das ist auch die gleiche Form von Referenz
Wir, der Pfeil kommt von Anforderung X,
die Rive Frequirement oder hier die Rived Requirement Anforderung ist.
Das ist die gleiche Aussage. Das würde man dieses,
diese Darstellung würde man wählen,
wenn Anforderungen X nicht auf dem gleichen Blatt ist,
dem gleichen Diagramm ist, wenn sie auf dem gleichen Diagramm ist,
kann ich diese verwenden.
Oder vielleicht nimmt man es dann, wenn sonst zu viele Linien werden.
Weil so bleibt das in räumlicher Nähe und das kann ja
irgendwo auf einem großen Diagramm sein. Sowas ähnliches gibt es also ganz häufig,
wir haben das hier oben auch schon, hier ist eine unspezifische,
abhängige Beziehung, hier wird es nicht weiter gesagt,
aber hier gibt es Master für Die Herkunft.
Hier haben wir das Wort Trace. Trace ist die Spur
, ist das Verfolgen, das Rückverfolgen. Also eine Anforderung
wird die Anforderung Y, wird verfolgt, die Anforderung X.
Und hier kann man das Ganze wieder so sehen zu Trace,
Two, hier steht die Richtung, durch das Tour angegeben.
Also ich folge Y folgt der Anforderung X.
So viel ist der erste Teil zu dem Anforderungsbeziehungen.
Es gibt aber noch weitere Beziehungen. So zum Beispiel die Beziehung,
dass man etwas verfeinern kann, zum Beispiel könnte eine Anforderung
Ein Anwendungsfall verfeinern, wie wir ja von dem Anwendungsfalldiagramm schon wissen,
dort besprochen hatten, ist die Anwendungsfalldiagramm sehr wenig aussagekräftig,
weil ich da nur den Namen der Anforderungen habe,
des Anwendungsfalls habe, des Use-Cases.
Und diese Use-Case-Beschreibung hatten wir als Methode der Erweiterung noch dazu.
Also hier kann ich das auch verfeidern, indem ich auf eine Anforderung verweise.
Die umgekehrte Form oder eine ganz andere Beziehung ist,
dass das eine das andere erfüllt. Also ich habe Eine
Anforderung und die wird erfüllt durch ein Element eines Systems.
Dieses Element des Systems ist dann verantwortlich für die Antwortung ist. Ja,
das kann ich machen, wenn ich die in gleichen Diagrammen hätte,
sag ich mal, dann könnte ich hier diese Stereotyp-Satisfy an eine Abhängigkeitsbeziehung einschreiten.
Aber das wird selten passieren, weil ich typischerweise in einem Diagramm,
wo Systembausteine sind, nicht gleichzeitig Anforderungen habe.
Möglich wäre das, die System-LV, bietet das nicht,
aber normalerweise würde ich das dann so machen,
dass ich an den Systembausteinen dranschreibe, das ist die Anforderung,
die dieser Baustein vorrangig erfüllen soll.
Das ist diese zugewiesene Verantwortung. Ja, und das ist am Ende auch das,
wo wir sagen, ja, da hat jemand entschieden,
ich baue jetzt diesen Systembaustein, damit diese Anforderung erfüllt wird dadurch.
Der kümmert sich, der Kümmerer. Okay, das Gleiche,
diese gleiche Zuordnung, diese Zuordnung muss ich prüfen. Ja,
ich muss zum Beispiel prüfen, ist jede Anforderung,
die ich meinem Anforderungsdokument habe, wir gehen zurück,
hier deswegen diese ID,
damit ich die wirklich auch tapellarisch auflisten kann und eindeutig kennzeichnen kann,
ist jede hier durch ein irgendwo im System,
im Systementwurf berücksichtigt, erfüllt.
Das Gleiche brauchen wir auch diese gleiche Abdeckung, brauchen wir
auch für Tests, Ist jede Anforderung irgendwo durch einen Test abgedeckt?
Wird die Antwort der Erfüllung der Anforderungen geprüft? Und diese
Erfüllung der Antwortung können wir einerseits so darstellen durch Verify,
durch diese Wiederabhängigkeit, Beziehung mit dem Stereotyp Verify,
oder in dem Fall zu einem Testfall verbunden,
oder indem wir hier so einen Strich unter Notizchen dran machen, mit Wayfys.
Das ist eine weitere Möglichkeit. Von diesen Dingen,
die wir hier dran gehängt haben, die hatten wir ja eben schon gesehen,
die Ralph From Trace bei Refined, Satisfied, Verified.
Das ist die eine Möglichkeit, Das grafisch darzustellen.
Zusätzlich haben wir aber auch die Möglichkeit, und das entspricht
der Praxis sehr stark, dass sich das einfach tabellarisch mache.
Wir haben ganz häufig Anforderungen als strukturierten Text,
das heißt, es gibt eine Nummer,
eine Überschrift und dann gibt es ein Stück Text und dann kommt der Nächste,
das macht man gerne mit Textverarbeitungssystemen,
da wird gelegentlich mal ein Bild dazu gehängt und das ist die Anforderungsbeschreibung,
damit diese Form der Anforderungsbeschreibung auch in Sysiamell abbildbar ist, hat man hier diese Tabellennotation hinzugegeben.
Besser ist natürlich, ein Bild sagt immer mehr als tausend Worte,
aber hier kann ich das auch textuell machen,
indem ich den Namen der Anforderung schreibe und dann den Text dass tabellarische Form,
wenn sie sich vorstellen, wird in einer Datenbank gespeichert.
Ich kann dann prüfen, ist die Antwortung 4711 denn irgendwo
im System repräsentiert durch ein Systemblock oder was auch immer?
Oder, und ist es durch einen Testfall geprüft?
Soweit zu den Anforderungen. Dazu hatten wir die Frage 2,
für welche Inhalte eignet sich CSML besser,
als UML und die Frage 3, wie wird die Verfolgung von Anforderungen bezeichnen?
Das war diese Beziehung Trace, zu der gehen wir gleich nochmal.
Die war hier, nein,
ins Vorher
Ja, also das Treys sagt,
hilft mir die Verantwortung zu verfolgen, von einer zu anderen,
bei der Zerlegung, ist es auch eine Form,
ich verfolge, wie die Anforderungen zerlegt wird,
wie ich Anforderungen auseinander ableite, aber ganz besonders,
wenn ich etwas, eine Anforderung erfüllt habe,
dann wäre dieses Satisfy.
Ja, also ich habe die Anforderungen erfüllt durch ein Stück
in meine Systemeentwurfs, hier in dem Beispiel im Block,
kann aber genauso gut eine Regel sein oder was auch immer.
Oder dieses durch einen Testfall auch nachverfolgen.
Das sind alles Möglichkeiten. Also diese ganzen Verbindungen hier,
auch die, die wir jetzt hier oben dargestellt haben,
sind Möglichkeiten, das zu verfolgen.
Das war Frage 3. Soweit erstmal zu diesem Abschnitt