Wir haben nun einige Modellierungssprachen schon kennengelernt und wir wissen, wie wir Anforderungen mithilfe von Modellen gestalten.
In diesem Kapitel 7 möchten wir uns damit beschäftigen,
wie wir Modelle einsetzen können, um den Entwurf möglichst gut zu unterstützen.
Wir starten im ersten Teil erstmal damit zu überlegen, was sind denn gute Modelle? Das Ganze folgt wieder dem Ansatz,
den wir ganz zu Anfang schon mal hatten,
wie man zu einer Modellierungssprache kommt,
diese Schritte 1 bis 4,
die haben sie schon mal gesehen, dass wir damit starten,
was sind denn denn die Ziele,
ja,
die zum Beispiel im Entwurf würden wir jetzt zum Beispiel
die Dekomposition würden wir nach fachlichen Aufgaben wäre ein solches Ziel
oder ein weiteres Ziel wäre,
dass wir Zeitverhalten erreichen
Und zwar solches Zeitverhalten wie vom Auftraggeber gewünscht. Und der Zweck
der Modellierung wäre dann, dass wir diese Entwurfsentscheidungen dokumentieren.
Das gehört hier also zum ersten Punkt.
Das zweite gehört hier, da wäre zum Beispiel das zweite,
dass wir... Dass wir Zusammenhänge darstellen.
Natürlich die Komplexität beherrschen
Und vielleicht noch zukünftiges Visualisieren vorstellbar machen, prüfbar machen.
Auswirkungen. Zum Beispiel von Änderungen oder Entscheidungen
prüfbar machen
Also, dass die ersten beiden Zeigen gehören zum ersten.
Und diese hier gehören zu dem zweiten Punkt. Ja,
und welche Aspekte jeweils dazugehören und welche Modellungssprache und sich mehrere verwenden,
das sind dann die Folgen, das sind dann die Entscheidungen,
die wir auf dieser Basis treffen können.
Wir werden insgesamt gehören hier die Fragen 1 bis 3 dazu. Ja,
die Frage 4 ist dann schon zum Abschnitt 7-2. Wir werden also versuchen,
eine Modellierungssprache zu finden und Entscheidungen zu treffen darüber,
welche Ausschnitte der Realität in ein Modell übernommen werden.
Mit Blick auf die Ziele und diese Ziele
sind zunächst zu betrachten, was wollen wir eigentlich erreichen?
Deswegen auch diese Überschrift 7.1, was sind gute Modelle?
Wir wollen gute Modelle erreichen. Und dabei geht es uns
natürlich auch um das Ziel
Ich möchte als Beispiel mal etwas nehmen, was wir gerade parallel,
einige von Ihnen besuchen, die Veranstaltungen, Softwarearchitekturen,
wir haben jetzt sogar zeitlich einen sehr engen Zusammenhang drüben bei Softwarearchitekturen,
haben wir auch gerade das Thema Entwurf.
Und hier beschäftigen wir uns damit, modellbasierten Entwurf zu machen.
Und deswegen habe ich hier mal eine Folie mitgebracht,
die wir natürlich in seinen Softwarearchitekturen, das ist eine englische Lehrveranstaltung,
gibt es das Gleiche in Englisch, aber das sind die Ziele,
die man mit einer Softwareentwicklung Softwarearchitektur verfolgt.
Und das sind natürlich die Ziele, die man dann hier
am Ende bei dem mit einem Modell unterstützen möchte.
Ja, also jetzt nur mal so im Kurzen dargestellt,
wir wollen hier nicht wirklich Softwarearchitekturentwurf lehren.
Das geht über die Veranstaltung hinaus. Hier ist das Ziel,
die geeigneten Modelle dafür aufzustellen. Und natürlich sprechen wir dabei
auch darüber, was denn so eine Architektur gut macht.
Ja, zum einen spielt es ein wichtiges Ziel,
die Effizienz, die Entwicklung effizient gestalten zu können.
Ja, effizient, effizientere Entwicklung, also man möchte die Entwicklung des Aufwand-Nutzen-Verhältniss steigern.
Effizient heißt ja, das Verhältnis zwischen Nutzen und Aufwand,
während effektiv heißt, dass das rauskommt, was ich möchte.
So, zum einen möchte die Architektur dabei unterstützen, dass ich inkrementell arbeiten kann.
Integrationsrahmen, dieses Wort soll bedeuten, ich kann die Teile,
die ich in Inkrementen entwickle, dann wieder zusammensetzen.
Ja, also für dieses Inkrementelle Projekt,
die Komponenten darstellen und ihr Zusammenwirken darstellen, das ist das,
was die Architektur unterstützen möchte.
Und tatsächlich bauen wir bei der Architektur ja Kästchen und Linien,
also Schnittstellen und die Komponenten sie verbinden und die Komponenten mit
ihren Verantwortlichkeiten
Gleichzeitig spielt es dafür, das spielt für effizient seine wichtige Rolle,
dass man in einem Projekt gut koordinieren kann, vor allem,
wenn es größer ist, brauchen wir Unterstützung für das Projektmanagement.
Und zwar für die Organisation, für die Führung,
durch den Projektleitung, auch für die Einblick durch die Leute,
die das Projekt begleiten oder die der Auftraggeber sind oder vielleicht auch als Verhandlungsbasis,
wenn es um Preise geht.
Dazu braucht der Projektleiter klare Aufgabenpakete,
die ja auch mal verschieben kann, nämlich aktive Führung heißt,
okay, der Termin rutscht jetzt irgendwie,
weil irgendetwas länger dauert,
das kann man nicht ganz verhindern,
auch bei bester Erfahrung nicht
Und dann muss es aber gelingen,
diesen einen Baustein zu haben, den man rausnehmen kann und
vielleicht in die nächste Version schieben oder einem anderen Baustein,
wo man sagen kann, den lassen wir weg.
Der ist nicht ganz so wichtig. Hauptsache, wir haben
die wichtigeren Bausteine. Und wenn das Ganze ein großer Modulit ist,
Big Ball of Mut heißt das manchmal im Neudeutsch.
Ja, also alles hängt irgendwie zusammen,
dann wird es nicht gelingen, einen Baustein rauszunehmen.
Aber wenn wir eine gute Architektur haben, dann können wir hier aktiv handeln.
Dann können wir daran der Projektleiter auch mal ein Stück rausnehmen.
Und er kriegt gesagt, vom Architekten, was er denn da rausnehmen kann.
Und die Architektur braucht deswegen. Und damit wäre,
das wäre, also das Ziel ist jetzt hier, Projekt,
Steuerung machen und die Modellierung muss dann Zuordnung von Abhängigkeiten darstellen.
Welche Abhängigkeiten sind, wo nämlich geringe Abhängigkeiten. So und
dann gleichzeitig wollen wir die Implementierung vielleicht noch voneinander unabhängig in verschiedenen Teams,
in verschiedenen Führungen, Firmen oder über den Erdball hinweg verteilt,
über verschiedene Unternehmen, verschiedene Länder machen.
Ja und auch dazu brauchen wir Komponenten, die Komponenten,
die klar, von denen klar ist,
wie hängen sie von anderen ab.
Deswegen unabhängige vom Implementierung ermöglichen,
dass sie möglichst wenig abhängen
Und dass sie das auch klar ist,
wer macht denn was? Damit man klar ist,
über welche Themen muss ich mich mit welchem,
mit wem von den anderen Entwicklern, von anderen Komponenten eben abstimmen?
Soweit effiziente Entwicklung, wir sehen hier fast gar nichts von Entwurfsmethoden.
Wir hören kein Wort von Objekte und Tierung. Ja,
wir hören falls von Modulen, wir hören was von Schnittstellen, von Entwurfsprinzipien.
Darauf werden wir gleich noch kommen. Also hier stecken hinter diesen Zielen,
die wir mit Softwarechitektur erreichen, stehen am Ende Entwurfsmethoden.
Und diese Entwurfsmethoden gut anwenden, gut prüfen,
das geht mit einer bestimmten Sorte von Modellen.
Dazu wollen wir
gleich kommen
Als nächstes steht hier Risiken minimieren. Auch ein sehr pauschales Ziel für eine Architektur. Tatsächlich möchte man ermitteln,
wo gibt es denn riesigen bezüglich Performance, riesigenbezüglich,
dass bestimmte Technologien nicht zusammenarbeiten, Interoperabilität, ja,
oder Risiken bezüglich nicht erfüllbarer oder schwer erfüllbarer,
weil exotische Anforderungen an eine Technologie, ja,
und man wird dazu müssen wir frühzeitig die Anforderungen kennen,
also dieses Wort Einflussfaktoren stammt aus mancher von dieser Architekturliteratur,
wo es darum geht,
das sollen Anforderungen sein
Schreiben wir mal kurz dran, damit Sie später noch wissen,
was es ist. Ja, und gleichzeitig muss ich
auch frühzeitig prüfen, ob denn die Anforderungen erfüllbar sind.
Auf der rechten Seite hat das fast alles diese beiden großen Punkte
Verständnis schaffen und Kernwissen konservieren halt beides etwas mit Verständnis und Kommunikation zu tun.
Kommunikation zwischen den verschiedenen Beteiligten, das Wort Stakeholder,
kennen hoffentlich alle, sind einfach nur Beteiligte an einem Projekt.
Ja, und zwischen denen, die haben ganz unterschiedliche Sichtweisen. Jemand,
der eher die fachliche Sicht mit Geschäft Geschäftsprozessen und Geschäftsregeln vor sich hat,
der versteht wahrscheinlich wenig von dem Technischen,
während viele Programmierer, die ganz genau wissen,
wie Transaktionen in dem und dem Sonderfall denn so anzusteuern sind,
die wissen vielleicht nicht nach dem,
wo die Geschäftsregeln ihren Inhalt herhaben.
Also zwischen den Leuten eine Übersetzung darstellen, für jeweils
die Informationen der jeweils anderen Seite präsentieren, verständlich machen.
Das ist ein wichtiges Ziel einer Architektur. Wenn wir dann überlegen,
ja okay, das ist das Ziel, Zweck ist hier
verschiedene Sichten darzustellen und die zwischen diesen Sichten Verknüpfungen herzustellen.
Ja, und dann könnten wir dann sagen,
welche Programmiersprachen das sind
Also nur, um es schon mal zu sagen,
also wir wollen Forderungen darstellen, wir wollen sich denn darstellen.
Das ist das, was wir hier brauchen. Klar,
wir wollen auch neue Mitarbeiter in unsere Projekte aufnehmen.
Dazu ist die Architektur gut geeignet, weil sie einen Überblick bietet,
weil sie verdeutlicht, wo die Zusammenhänge sind.
Und gleichzeitig brauchen wir etwas, auf das wir uns beziehen können.
Ein Leitbild im Groben, mit einer groben Darstellung,
wo ja die Strategie dargestellt wird.
Referenz, wo man etwas lernen kann für andere Projekte oder Erfahrungen
daran festmachen kann
Das ist soweit die kurzfristige Kommunikation, die ich während der
Projektbearbeit brauche. Und im unteren Teil hier das Konservieren,
das heißt für Langfrist, große Systeme leben typischerweise länger,
weil schon, weil sie eben mehr Aufwand kosten,
um sie zu erstellen.
Dieser Aufwand muss ich irgendwie bezahlt machen. Und deswegen muss
ich das Wissen für lange Zeit erhalten, konservieren.
Zum einen möchte ich es konservieren und weiterverwenden in anderen Projekten.
Zum anderen ist das irgendwie ein wichtiger Wert in den Softwarearchitektur,
war die Entscheidung,
die drin steht,
lange tragen
Und gleichzeitig sehen wir an den Sachen, die wir für aufgeschrieben haben.
Das und das ist so und so gebaut oder warum
ist das so gebaut und wir merken dann vielleicht später,
ist doch nicht so ganz optimal,
dann können wir das hier beschriebene prüfen und sagen,
was davon ist denn zu verbessern und wie kann es verbessert werden.
Also Verbesserung ist nur dann möglich, wenn wir es aufgeschrieben haben.
Also das Letzte hat hier viel mit Entscheidungen zu tun.
Wir haben ja auch in der Gliederung gerade gesehen,
später kommt auch das Beschreiben von Entscheidungen. Soweit erstmal grober Überblick,
was will Softwarearchitekturentwicklung und wir können auch noch mal weitergehen,
was ist denn dabei das Ziel der Modellierung dabei.
Ja, also für das, klar,
für das Verstehen möchte ich, dass ich diese Verständnis schaffen,
durch geeignete Modellierungssprache habe, die Modellierungssprache angepasst an diese Stakeholder.
Ja, das Kernwissen formalisiert heißt Kernwissen konservieren,
heißt auch unabhängig von dem Menschen, der es gerade bearbeitet.
Also so ein UML-Jahrkram, was ich nur verstehe,
wenn ich den Autor dazu sprechen höre.
Das ist nicht nachhaltig. Das geht nicht über längere Zeit
. Das heißt, wir brauchen irgendwie Formalisierung
Wir brauchen eine klare Definition von Syntax und Semantik.
Gleichzeitig wollen wir nicht an einem bestimmten Entwicklungswerkzeug hängen,
wenn der Hersteller das nicht mehr unterstützt,
können wir unsere Modelle wegschmeißen oder wenn der Mehrsteller sich plötzlich
ein tolles Lizenzmodell ausfällt, dann werden wir arm davon.
Ja, also wir möchten ja auch mal die Chance haben,
das Werkzeug zu wechseln und die Modelle mitzunehmen.
Und natürlich wollen wir auch Änderungen leicht erkennen können,
wo sie zugeordnet sind, worauf sie sich beziehen,
ob sie prüfen können,
ob sie wirklich
ihre Ziele erfüllen
Wir wollen prüfen können, ob denn das System seine Ziele erfüllt.
Ja, wenn wir das mal hiermit vergleichen,
so war das einerseits, dass wir hier die Anforderungserfüllung prüfen,
ja, gleichzeitig, dass wir Projektplanung führen erlauben.
Und das ist das, braucht Bewertung. Man muss der Projekt,
klar, da muss ja wissen, wo stehen wir gerade.
Ja, und das wäre eine Möglichkeit. Dieses Risikenerkennen haben wir auf beiden Seiten,
ja, haben wir hier bei den Zielen der Architektur und bei dem,
was dann die Modellierung soll,
nämlich wir wollen die entsprechende Modellierungssprache, die diese Informationen,
die wir brauchen,
Zum Beispiel für Performance, für Zuverlässigkeit,
für in der Operabilität oder andere Qualitätseigenschaften. Ja,
bleibt noch das erste hier effiziente Entwicklung, Aufwand, Nutzenverhältnis.
Aufwand, Nutzenverhältnis einmal, geringen Aufwand. Das heißt,
Modelle sollen leicht erstellbar sein. Leicht erstellbar im Sinne von,
sie sind gut erlangbar, sie sind, erlauben eine hohe Flexibilität.
Und schon vielleicht auch, dadurch sind, man muss nicht
so viel Lernerwand reinstecken, weil es ist alles ganz intuitiv.
Ich habe keinen hohen Formalisierungsgrad,
wie beispielsweise bei einem Petri-Netz oder einem Modell im Z
in einer formalen Programmiermodellierungssprache
Ja, also bringen den Aufwand. Und dann, dass ich jedem,
jedem Stakeholder die Sicht anbieten kann, die er möchte.
Gleichzeitig wollen wir also, wollen wir aberen, das hat
mir hingesagt, wollen wir, Werkzeuge zur Bewertung einsetzen.
Wenn wir hier oben, dass die höchste Flexibilität haben wir sicherlich,
wenn wir natürliche Sprache erlauben. Wenn wir freie Grafiken erlauben,
wenn wir beliebige Typen von Pfeilen und von Elementen erlauben.
Ja, aber wenn wir diese Elemente,
diese Freiheit immer haben, kann kein Werkzeug eine Auswertung machen.
Das heißt, das widerspricht sich ein bisschen.
Am besten wäre es, wir haben hier eine klare Syntax
und Semantik
Ja, dann lassen können wir es in den Werkzeugestützen Bewertungen machen.
Zum Beispiel können wir sagen, okay, jedes Interface,
wenn da ein Signal dran ist, muss das irgendwo herkommen.
Es muss eine Quelle da sein. Oder wir wollen prüfen,
dass jede Anforderung irgendwo adressiert wird. Klar, wir können,
das Tool kann kommen, bewerten, ob das inhaltlich korrekt ist.
Aber wir können wenigstens verfolgen, ja,
da ist ein Häkchen dran und da ist kein Häkchen dran.
So, dann haben wir ja noch als weiteren Punkt hiermit aufgenommen,
der nicht bei dem Vorderen so unmittelbar dasteht, Komplexität beherrschen.
Wir haben immer große, wir müssen davon ausgehen,
dass wir immer große Modelle haben und diese großen Modelle brauchen müssen viele Zusammenhänge darstellen.
Und da kann ich halt zur Gliederung Abstraktion benutzen,
Hierarchien bilden oder auch die Module nutzen, um etwas verteilt,
entwickeln zu können.
So, soweit das Beispiel mit den Zielen der Architektur.
Also wir haben angefangen mit Zielen von Softwarearchitekturen,
hier mal ganz kurz auf der nächsten Folie etwas ausführlicher.
Und dann haben wir überlegt, welche Ziele davon müssen denn
Modelle unterstützen
Viele von den Zielen haben wir von der vorgehenden Folie wiedergefunden,
ja, wie zum Beispiel das mit dem Aufwand oder dem Verständnis oder dem Kernwissen.
Manche Sachen sind auch nicht so direkt bei den Zielen da,
aber sie muss natürlich bewertet werden, ja,
und es muss die Komplexität beherrscht werden.
Das ist nicht so richtig als Ziel genannt worden,
aber wir wissen, dass das System, solche Systeme,
die wir hier bauen, groß sein können.
Okay, weiter geht es jetzt mit dem Teil 3,
mit den Ausschnitten, die wir darstellen wollen.
Auch dafür müssen wir irgendwie eine Antwort geben. Natürlich können wir
das nur machen, wenn wir ein konkretes Beispiel haben.
Wir werden noch auf konkrete Beispiele kommen
Aber was man entscheiden muss, ist zum Beispiel,
wie detailliert kommt denn das Ganze?
Wie vielen Informationen zu jedem Teil haben wir denn?
Also einerseits wollen wir es möglichst allgemein darstellen, damit man
keinen Einstellungseinstiegsaufwand hat. Andererseits wollen wir es sehr genau darstellen,
damit man es genau prüfen kann. Ja, also Einfachheit,
Übersichtlichkeit, das hilft, dass man es gut versteht.
Das sind wenig Details drin. Also das Ganze ist
sehr abstrakt. Für die Bewertung, die Validation,
brauchen wir eigentlich einen kompletten Ablauf.
Ein komplettes Zustandsdiagramm, eine komplette Menge von allen Werten
und Wertemengen
Und Gültigkeitsbereiche. Das heißt, da brauchen wir viele Details.
Das widerspricht sich. So etwas ist schwieriger.
Ein weiteres Beispiel für Dinge, wo wir entscheiden müssen,
wie viel wir denn mal nehmen, ist die Frage Redundanz.
Redundanz meint, dass wir eine Information an mehreren Stellen haben.
Manche sagen, okay, gerade der Informatiker lernen,
dass man das nur einmal alles macht.
Und deswegen keine Redundanz
Aber ein Text, ganz ohne Redundanz, ist schwer zu lesen.
Und ein Modell, ganz ohne Redundanz, ist schwer zu verstehen,
weil ich ständig irgendwie hin und her spiege. Am besten,
ich habe doch mal einen Überblick über das Verhalten,
vielleicht im Zustandsdiagramm, auch noch, wenigstens,
dass die einige Zustände erwähnt werden im Strukturdiakrank.
Also es wäre doch sinnvoll, einzelne eigene Sichten, einige Sichten darzustellen.
Schon, dass sich Komplexität beherrschen kann. Und deswegen soll
die Zerlegung in Sicht nur so streng sein, wie wir sie denn brauchen.
Nur dann hilft es uns. Ja, also die Frage,
wenn wir etwas ganz Redundanz Null würde bedeuten,
wir haben alles separat, nichts kommt mehrfach vor,
Es gibt sehr schwer verständliche Modelle.
Wenn es überlappend ist, zu viel, haben wir einen hohen Änderungsaufwand.
So, und gleichzeitig, wenn wir Zusammenhänge verstehen wollen,
ist es gut, wenn man Zusammenhänge aus verschiedenen Sichtweisen darstellt und die dann zusammenführt.
Auch das ist mit Fredundanz verbunden. Nämlich,
dass wir dann über Sichten eine Verbindung erreichen,
aber trotzdem jeweils klar ist,
was ist damit,
was ist damit gemeint
Ja, und dann das Letzte, was hier in
diesen Vierer gespannt ist, war dann die Modellierungssprache.
Die möchten wir auch immer noch kurz anschauen.
Beispiele für Sichten sind ja auch gleich angegeben. Diese Sichten sind
die sogenannten Siemens-Sichten. Es gibt ein Forschungsinstitut von Siemens in den USA,
wo die Berater da anleihen genommen haben,
dass Siemens 4-4-Fews Model, Kontext heißt das umgebende System,
Oder Umgebende, scheinbar umgebende Systeme.
Die umgebende Organisation, also zum Beispiel ein Unternehmen mit einer
betrieblichen Struktur von Niederlassungen, Abteilungen, Projekten und sowas.
Und natürlich spielen hier auch Personen mit rein. Und hier
ist die Frage, wie stelle ich das Ganze dar?
Wie sind die Strukturen? Wie sind die Kommunikationsbeziehungen zwischen diesen
Systemen? Wie sind die Aufgaben und Rollen
der Organisation
Aufgaben und Rollen von Personen. Ja,
das sind alles Dinge, die ich hier darstellen kann.
Und da kann ich Struktur und also das Ganze,
die ersten zwei hießen Strukturdiagramme,
die zeichnen das Statische und die Zustandsaktivitätsdiagramm, das sind Verhaltensdiagramme,
die dann die Reihen folgen und Zustände und sowas zeigen.
Diese beiden, also das ist das Umgebung,
das ist die Umgebung.
Hier ist das
zu entwickeln,
das System
Und zwar die Teile und deren Beziehungen, das wäre die Struktursicht.
Einfolge gibt es da nicht in der Struktursicht,
die Reihenfolge steht in der Verhaltenssicht, zu der wir gleich kommen,
in der Struktursicht sind, vor allen Dingen Abhängigkeiten.
Zum Beispiel, da gibt es etwas, das gehört zusammen.
Das eine ist Teil von dem anderen.
Oder es gibt Dinge, die geben zusammen ein großes Ganzes.
Oder sowas wie Vererbungsbeziehung, also Generalisierung, Spezialisierungsbeziehung,
das ist ein spezielles von dem und dem,
das ist ein spezieller Server,
das ist ein spezielles Datenbanksystem
Das ist mit Beziehungen gemeint, ja,
die wir in diesem Diagramm darstellen. Diese Teile,
das könnten zum Beispiel Komponenten sein, das könnten Klassen sein.
Also dazu gibt es das Kommunentendiagramm, das Klassendiagramm der UML.
Die haben wir ja schön kennengelernt. Für die Verhaltenssicht,
da geht es darum, vom zu entwickelnden System Reihenfolgen von
irgendetwas Nachrichtenaustausch Oder Zustände darstellen, das ist nur ein Ausschnitt.
Es gibt noch, vielleicht machen wir hier noch drei Punkte
hin und hier oben auch drei Punkte, dass sie wissen,
es geht noch weiter.
Ja, also dazu können wir zum Beispiel,
dass UML-Zustandsdiagramm verwenden, Sequenzaktivitätsdiagramm haben wir kennengelernt.
Das Interaktionsübersichtsdiagramm haben wir nicht behandelt. Diese Diagramme helfen uns
, Reihenfolgen darzustellen, den Nachrichtenaustausch oder sowas.
Es gibt auch sogar Diagramme für wirklich das Zeitverhalten,
die haben wir hier nicht
Ja, und dann gibt es noch die Abbildungssicht,
das hat damit zu tun, dass wir einerseits die Installation irgendwo vornehmen.
Elemente zur Ausführung können zum Beispiel sein Server Netzwerkelemente,
bestimmte Server, wo Daten drauflaufen, zum Beispiel Datenbanksysteme.
Irgendwelche Elemente, die zu viel zur Laufzeit haben,
das ist das erste Stück von Laufzeit und da könnten wir
das UMLD-Komponentendiagramm, ich füge nochmal hier dazu, UML-Deployment-Diagramm.
Und gleichzeitig gibt es hier noch was Zweites,
nämlich die Zuordnung zu Arbeitspaketen
Und zwar Entwurfselemente, das sind dann diese Komponenten. Und Arbeitspakete,
die wir miteinander zuordnen, da könnten wir solche Arbeitspakete werden,
dann Personen oder Teams zugeordnet,
aber diese Personen und Teams,
das macht dann der Projektleiter und das wäre hier dieses Paketdiagramm.
Das Paketdiagramm ist gut geeignet,
um Arbeitspakete darzustellen
So, damit soweit erst mal dazu, was wir,
wie wir das im Beispiel für eine Architektur machen, ja,
also das haben wir damit gleichzeitig die Frage 1 beantwortet,
welche Ziele hat denn Architekturentwicklung und wie müssen wir damit da vorgehen,
was sind die Ziele des Modells und was für Modellierungssprachen würden da in Frage kommen.
Gleichzeitig haben wir hier einmal sich denn dargestellt,
diese Sichten sind erst mal das, was man für einen Softwareentwurf braucht,
was häufig verwendet wird, diese vier Siemens,
vier Sichten, es gibt durchaus auch andere Sichten.
Hier sind diese vier Sichten dargestellt. Es gibt auch manchmal noch Sichten,
wo Abläufe separat dargestellt werden oder wo Ausfallwahrscheinlichkeiten dargestellt werden,
wenn wir eben Ausfälle ein wichtiges Thema haben.
Ja, genau, damit haben wir schon ein bisschen ein Beispiel gebracht.
Die Frage 1 bis 3 beantwortet und weiter wird es
dann gehen, wenn wir uns über gute Modellierung unterhalten.
Gute Modellierung kommt ja daher, dass wir versuchen,
alle Eigenschaften darzustellen, die wir für das Modell,
für die Arbeit mit dem Modell brauchen. Dazu verweisen wir,
das ist also hier der Abschnitt 7-1-
2. Wir wollen damit beginnen, dass wir gute Modelle,
nein, das sollte ja nicht gemalt sein,
sondern nur rot eigentlich.
Da wollen wir den anderen Pointer, ja,
wir wollen also Modelle haben, die den Modellierungszweck unterstützen,
zum Beispiel alle Informationen,
die wir für unseren Teil brauchen
Sie werden vielleicht sagen, warum nicht alle, warum nur alle relevanten.
Sie erinnern sich, ein Modell, beim Modell lassen wir Sachen weg.
Wir lassen Sachen weg, die wir nicht brauchen.
Und das ist genau das, was wir hier dargestellt haben.
Wir haben gesagt, wir brauchen die Sachen,
relevant ist, was dem Zweck der Modelle dient,
relevant ist, was das Ziel unterstützt.
Und deswegen, wir nehmen nur, wir brauchen nur die relevanten.
Deswegen haben wir über das eben gesprochen.
Beispiel Surftwarearchitekturentwicklung. Und wir wollen alles haben,
was wir brauchen, um mit dem Modell zu arbeiten.
Das heißt, wir wollen
das eigentliche arbeiten
Dem Modell unterstützen. Das ist ja die Nutzung. Ja,
und hier unten steht jetzt ein paar drei solche Nutzungen,
die wir brauchen. Die Kommunikation, das wäre besonders möglich,
wenn wir so einfache handschriftliche, informale, flexible Modelle haben.
Verifikation, Validierung. Wir haben nicht mehr die Unterscheidung,
was ist denn was von den beiden?
Die Amerikaner machen es sich. Einfach, die sagen einfach VNV.
Wir machen uns das so ähnlich einfach. Es geht hier
darum zu prüfen. Ja, die Modelle müssen erlauben,
dass wir prüft, dass wir sie prüfen.
Dass wir prüfen, erfüllen sie denn die Anforderungen,
zum Beispiel Richtung Performance,
Richtung Zuverlässigkeit oder sowas
Und vielleicht sogar noch hier dieser Punkt,
mit der letzte Punkt, der so ein Kringel gekriegt hat,
dass wir sogar noch eine maschinelle Auswertung für Simulation,
für Code-Generierung, für Ableitung von Dokumenten oder so etwas machen können.
Das wäre das Ziel, was wir hiermit erreichen,
dass wir es erstmal gut geeignet ist.
Und dann wollen wir sogar noch mehr, nämlich wir wollen den Aufwand kürzen,
wir wollen den Aufwand verringern, das Ganze soll ganz leicht gehen.
Und zwar den Aufwand für die Nutzung, dass ich also damit arbeite,
aber auch für die erstmalige Nutzung das Erlernen.
Und wenn ich an den Modellen etwas vornehme,
was sich ändern muss, das braucht machen wir da jeweils auch.
Und wenn wir jetzt das Beispiel nochmal nehmen von Softwareentwicklung,
das ist ja unser Thema, wir wollen Software entwickeln für bestimmte Ziele.
Und wenn wir, und diese Ziele sind vielleicht,
häufig sind es auch qualitative Ziele, manchmal auch funktionale,
das hängt ein bisschen davon ab,
was für unser System wichtig ist.
Sei es zum Beispiel, dass wir Zeitverhalten brauchen, ja,
dann brauchen wir Modelle, die zeitliche Reihenfolgenzeit dauernd darstellen können.
Interessiert uns Robustheit, dann müssen wir irgendwie Fehlermodelle haben
und Ausfallwahrscheinlichkeiten
Fehlermodelle sagen uns, wie häufig tritt denn welcher Fehler auf?
Wie fließt das zusammen? Ist es am Ende,
füllen wir zwei Sachen zusammen machen?
Wird es dann häufiger oder wird es weniger häufig? Ja,
also dass solche Modelle brauchen wir für Robustheit, für Security,
brauchen wir dann Modelle, die vielleicht darstellen, was ist denn schützenswert?
Ja, und diese Punkte hier unten,
die hatten wir schon genannt, auf einer vorhergehenden Folie.
Ich möchte hier noch ein Beispiel bringen, dieses Beispiel soll uns verdeutlichen,
wie machen wir das für zwei konkrete Ziele?
Ja, wir hatten eben schon was mit Performance,
wenn wir zum Beispiel Security
als wichtiges Ziel haben
Dann brauchen wir Modelle, die das darstellen, was ich für Security-Prüfungen brauche.
Und das wäre zum Beispiel, wenn ich schauen will,
welche Daten sind denn von wem zugreifbar.
Ja, dann brauche ich Datenflüsse oder Informationsflüsse,
wenn das ein bisschen allgemeiner formuliert werden soll.
Das ist nur ein unterschiedliches Wort. Ich muss also wissen,
wo gehen die her, wo kommen die her,
wo gehen die hin, wer hat alles drauf Zugriff,
mit welchen Operationen kann ich damit arbeiten und wie werden die Daten auch verteilt,
um abschließend abschätzen zu können, was damit passiert.
Wir wollen wissen, wie können wir Angriffe vermeiden und
da müssen wir hypothetische Angriffe analysieren
Das können frühere Angriffe sein, das können Sachen sein,
die uns ein Experte dann zeigt. Jedenfalls wollen wir Ursache
und Wirkungsbeziehungen darstellen. Und wir wollen prüfen, ob das,
ob die Modelle, ob die Elemente unabhängig voneinander sind.
Damit wollen wir also möglichst wenige Abhängigkeiten haben, um das zu prüfen.
Das ist auch ein wichtiger Punkt. Soweit zur Security.
Für Zuverlässigkeit geht es darum, dass wenn Systeme schnell wieder
lauffähig macht, beziehungsweise dass sie gar nicht erst ausfallen.
Und dazu geht es darum, dass wir prüfen,
welche Fehler sind denn eine Rolle für als Ursache, für Fehlverhalten.
Oder dass wir das gar als Kettenform darstellen, wenn das passiert,
dann ist das gestört und dann wird das nicht mehr funktionieren.
Und das können wir mit den Mitteln der Statistik zum Beispiel auch machen,
indem wir unser Modell statistische Informationen über Ausfallwahrscheinlichkeiten aufnehmen.
Und die können wir bewerten, zum Beispiel danach,
wie schlimm ist es denn für uns?
Wie groß ist denn der potenzielle Schaden? Weil der steht
dann dafür da, dass man eine Rechtfertigung hat,
um da Aufwand zu investieren
Soweit zu dem Zweck der Modellierung,
wenn wir nochmal zurückgehen, was wir hier brauchen.
Also wir hatten den Zweck der Modellierung. Wir hatten die
Ziele Zweck der Modellierung und jetzt ist noch die Frage,
wie sieht denn das mit dem Programmiersprachen aus, die wir da brauchen.
Und das ist erstmal sehr vom Projekt abhängig. Ich habe ja
mal ein paar Beispiele, mehr oder weniger willkürlich zusammengenommen.
Für wen ist die Sicht geeignet und was sind die Aspekte,
die da dargestellt werden? Sie können durchaus hier sich vorstellen,
dass es da noch mehr gibt.
Aber ich habe einfach nur die zwei wichtigsten rausgenommen
Zum Beispiel der Auftraggeber, der möchte wissen, wie ist der mein System,
was ich hier baue, eingebettet in die Umgebung.
Der Tester möchte das gleiche Wissen und der Entwickler auch.
Und wie sieht dann das System aus? Das wollen die
auch alle drei wissen. Wenn ich eine Sicht brauche,
um ein System zu ändern, um es umzugestalten,
dann bräuchte ich gerne wissen, wie hoch,
wie teuer wird denn das Ganze?
Wie aufwendig wird das denn? Was hat es für Nebenwirkungen
? Was hat es für, erreicht es denn deine positiven
angestrebten Wirkungen? Das heißt, wir wollen die Auswirkungen von
Veränderungen prüfen
Und das können wir zum Beispiel machen,
indem wir statische Zusammenhänge untersuchen, also diejenigen alle ohne Zeit verhalten,
sondern die, die eher Zusammengehörigkeit zeigen, die zeigen,
wer hat welche Rolle, so etwas.
Und wir brauchen natürlich auch Informationen über das tatsächliche Zeitverhalten,
die Rollen, die, die Zuständigkeiten, die in Zuständen zugeordneten und Zustandsübergänge.
Also sowas brauchen wir hier auch noch. Wir hatten eben das Beispiel Security,
wo ich gerne missen möchte, was sind denn die schutzwürdigen Sachen?
Oder dass ich ein Modell habe, das hypothetischen Angreifers.
Ich sage, er würde das gucken, das gucken,
das gucken und dann kann ich Barrieren einziehen.
Und dass er nicht so viele Informationen findet,
beziehungsweise gar keinen Zugriff bekommt. Hat natürlich die Forderung,
dass der tatsächliche Einbrecher sich auch so verhält,
wie das, was wir erwarten haben.
Ja, ich habe hier noch eine weitere Eigenschaft aufgenommen, Performance.
Dabei geht es darum, zunächst erst mal zu erfassen,
welche Verarbeitungsschritte gehören dazu. Wie viel Dauer hängt da jeweils
dran? Und dann können wir dem ein weiteres Modell über
unsere verfügbaren Ressourcen. Rechner, Leistung,
Speicherplatz zu etwas
Ein letztes Beispiel Verfügbarkeit werden eben die Zuverlässigkeit, es ist sehr nah verwandt.
Da möchte ich zum Beispiel darstellen, was sind die Störungen,
die ich erwarte und worauf wirken die sich aus?
Oder welche Behandlungsmöglichkeiten, welche Lösungsmöglichkeiten habe ich denn hier?
Zum Beispiel, dass ich jetzt sage, okay, hier,
ich stehe spendiere den Leuten noch ein paar mehr Dokumente, Dokumentationen.
So, soweit erst mal das, was wir sagen,
gute Modelle und jetzt machen wir einen kurzen Cut
und machen im nächsten Video das Kriterien für gute Modellierung