Im Abschnitt 7.5, wo wir über modellbasierte Architekturbeschreibung sprechen wollen,
geht es wieder darum, wie müssen Modelle aufgebaut sein,
was müssen Modelle für Tätigkeiten unterstützen.
Eigentlich haben wir schon ganz viele dieser Punkte,
die zur Architekturbeschreibung gehören, vorher besprochen,
denn wir haben schon über Entscheidungen gesprochen.
Wir haben über fachliche Architekturen besprochen und die Entwurfsprinzipien ebenfalls.
Es gibt ein paar Dinge weiter und wir setzen das bei
technischen Architektur bei Entwicklung der technischen Architektur im nächsten Abschnitt fort
Als Frage finden Sie hier lediglich,
wie sollte die Beschreibung einer Architektur aufgebaut sein,
wo aber natürlich dahinter steht, dass man sagen muss,
warum sollte die Beschreibung so sein?
Das heißt, das Ganze hängt irgendwie mit den Zielen zusammen.
Wir hatten über die Ziele ja schon gesprochen,
ich gehe erst mal zu dem Abschnitt 7,5.
Dort die Ziele hatten wir auf Folie 5 schon mal dargestellt.
Ich springe einfach nochmal zurück, um die nochmal zu zeigen.
Sie können das ja dann
immer auch tun
Worum geht es? Effiziente Entwicklung, Verständnis und das finden wir,
das muss die Modellierung unterstützen. Wo ist sie hier? Ja,
also für die Komplexität wollen wir es schaffen, Abstraktion,
Verfeinerung zu ermöglichen, zum Beispiel durch die Dekomposition,
durch Sichten können wir benötigte Informationen für eine bestimmte Sichtweise,
für einen bestimmten Stakeholder darstellen.
Jemand, der sich vor allen Dingen um die Installation kümmert,
jemand, der sich vor allen Dingen für Performanceziele kümmert,
ob die erreicht werden, jemand, der sich um Sicherheitsfragen kümmert,
möchte andere Informationen über das komplexe System,
was da entwickelt werden soll, haben.
Und deswegen braucht er eine eingeschränkte Form der Sichte.
Die Sichten hatten wir vorher schon mal dargestellt. Da hatte
ich mir notiert, Folie 8 und Folie 12. Ja,
also hier gab es solche Vorschläge für 4 Sichten,
wie sie mit manchen UML angelehnten Methoden dargestellt werden.
Und auf der Folie 12 waren Beispiele für Sichten.
Aber wie gesagt, das sind nur Beispiele.
Es kommt immer darauf an,
welche brauchen sie
Das Entwickeln der Sichten, die sie wirklich brauchen, hängt sehr davon ab,
welche Ziele stehen im Vordergrund. Wenn Performance im vordeutschen Grund wünscht,
die Security im Vordergrund, Verfügbarkeit, bereiten sie jeweils,
diese Informationen für die betreffenden Bearbeiter auf, die diese benötigen,
um Entscheidungen zu treffen, um bewerten zu können,
was da passiert, um zu bewerten können,
ob das System, wenn es dann mal fertig gebaut ist,
das richtig erfüllt.
Die Architektur ist immer da für frühzeitige Prüfungen
Das war der Punkt, Informationen bereitstellen. Dann ist immer
auch die Frage, wie flexibel können wir das halten?
Wenn wir keine maschinellen Prüfungen brauchen, keine Tool-Unterstützung für die Bewertung,
zum Beispiel eine modellbasierte Entwertung, Bewertung von Performance-Eigenschaften.
Wenn wir das brauchen, brauchen wir natürlich irgendwo auswertbare Ketten von Informationsfluss,
Verarbeitungsketten, wo ein Werkzeug zusammenrechnen kann,
wie ist denn die maximale Zeitdauer dafür?
Das heißt, wir brauchen für jeden einzelnen Schritt
eine Zeitdauer
Diese Zeitdauer muss halbwegs formal sein.
Die Bedeutung wird ganz selten formal beschrieben. Das heißt,
funktionale Korrektheit ist in den wenigsten Architekturbeschreibungen enthalten.
Wir kommen gleich noch zu ADLs als spezielle Form.
Aber andererseits soll das Ganze auch schlank sein. Auf effizient,
sie erinnern sich, Aufwand, Nutzenverhältnis steckt hier drin.
Und das bedeutet, wir wollen zu wenig wie möglich.
Dieses so wenig wie möglich hatten wir bei Entwurfsbeschreibungen
bei Entscheidungsbeschreibungen
schon mal
Da ging es darum, dass man diese, wo waren die Sollet-Prinzipien?
Moment, ich zeige sie Ihnen gleich nochmal.
Bei den Entscheidungen, da hatten wir Folie 14,
habe ich mir notiert, genau Folge 15, ja.
Also hier, wo wir wirklich so ganz minimal in Form
eines Satzes beschreiben, was ist denn dahinter?
Aber bitte diesen Satz nicht weglassen, ja. Leider fehlt
das sowas in ganz vielen Dokumentationen. Also das sind,
das ist mit schlank gemeint. Nur auf das Wichtigste konzentrieren. So,
wenn wir Prüfungen brauchen, Prüfungen zum Beispiel, um etwas nachzuweisen,
dem Auftraggeber nachzuweisen oder einfach um nur selbst Sicherheit zu haben,
über die frühen Entscheidungen, die mit Architekturentwicklung zu tun haben.
Dann müssen wir in irgendeiner Weise formale Beschreibungen haben.
Das Gleiche trifft zu, wenn wir irgendwie etwas generieren wollen.
Mit generieren ist gemeint Software generieren, Konfigurationen generieren. Zum Beispiel,
wir wollen ein Netzwerk initialisieren, entsprechend der Vorgaben der Architektur
Das wäre, oder manchmal auch nur die Dokumentation erzeugen.
Nutzerhandbücher oder so etwas anpassen an den aktuellen Entwicklungsstand.
Auch dafür brauchen wir formal komplette Syntax und Semantik und entsprechend auch komplette Beschreibungen.
Ja, dann dieses auf das weniges Wesentliche reduziert,
reicht uns dann nicht aus. Außerdem müssen wir darauf achten,
dass wir Veränderungen, die während der Entwicklungszeit passieren und danach passieren,
dass wir diese Veränderungen so unterstützen, dass man sehen kann,
wohin Auswirkungen von Veränderungen führen.
Auswirkungen von Veränderungen, Vorhersagen. Denn man möchte immer wissen,
wenn ich das ändere, wie aufwendig wird denn das Ganze und
das zweite ist Veränderungen vollständig durchführen, nämlich alle betroffenen Teile Volländerungen vollständig.
Durchführen soll das heißen, alle betroffenen Teile wirklich auch erfassen.
Und damit möchte man das dann eben erreichen, Konsistenz,
Vollständigkeit, Widerspruchsfreiheit zu erreichen. Soweit zu diesen,
zu diesen Eigenschaften, vielleicht schreibe ich noch einmal komplett oder nicht komplett,
ganz in wenigen Stichpunkten wollen, worauf es hier ankommt.
Ich packe das mal hier oben hin,
da ist auf meiner Folie gerade was frei,
da mache ich, brauche ich nicht noch ein extra Blatt,
nehme Sie gerne ein extra Blatt, wenn das bei Ihnen ein bisschen enger wird.
Also Dass ich... Frühe Entscheidungen dokumentiere,
dokumentieren heißt immer auch beschreiben und prüfen.
Nämlich, da habe ich noch nichts Lauffähiges,
aber ich möchte prüfen, zum Beispiel durch Simulation.
Diese Eigenschaften bewerten es mir einen separaten Punkt wert
Damit, mit solchen Eigenschaften ist gemeint, zum Beispiel Performance,
zum Beispiel Sicherheit, zum Beispiel Verfügbarkeit,
aber auch solche Sachen wie Wartbarkeit oder Deployability.
Das ist ein wichtiger Punkt, dann diese Frage
der Dekomposition unterstützen
Diese Dekomposition war ja eigentlich, wir zerlegen ein Teil in Unterteile,
in Komponenten oder Elemente, wie auch immer die heißen, Subsysteme.
Und diese Zerlegung muss natürlich irgendwie beschrieben sein, was ist denn die Verantwortlichkeit?
Also wir brauchen Komponenten und deren Schnittstellen oder ich schreibe halt das Zusammenwirken.
Diese Zuweisung von Verantwortlichkeiten, die wir schon hatten, War ein wichtiger Punkt.
Ja, und ja, genau. Dann müssen wir noch prüfen,
ob wir die technischen Mittel, wie die denn wirken,
die technischen Eigenschaften, die wir,
das ist ja ein ganz wesentlicher Punkt, der Architekturentwicklung,
dass wir die technischen Eigenschaften haben.
Doch das ist ein Punkt, den wir in den nächsten,
der nächsten, im nächsten Abschnitt noch behandeln werden.
Deswegen verschiebe ich das mal dahin. Ich möchte Ihnen vorstellen,
was für Sichten denn die verschiedenen Methoden vorschlagen.
Die Methode Architecture Triven Design 8DD 3.0,
den da parallel laufenden Veranstaltungssoftwarearchitekturen im Zentrum steht,
die schlägt zum Beispiel drei Gruppen von Sichten vor.
Einerseits, was dort Module Structures heißt,
da geht es darum, statische Eigenschaften zu beschreiben.
Eigenschaften und Beziehungen Also alles das Statische, es gehört zueinander,
das wäre hier die Dekomposition. Ja, es benutzt sich,
Layer ist nochmal eine spezielle Form der Modulstruktur,
wo man in eine bestimmte Richtung des Zugriffs nur hat,
nur von den Oberen zu den Unteren.
Die Unteren dürfen auf die Oberen nicht zugreifen und die
Oberen dürfen dafür nicht die Unteren sich darauf verlassen.
Die Generalisierung und auch Datenstrukturen spielen dabei eine wichtige Rolle.
Auch das sind statische Beziehungen, statisch im Sinne von strukturell
im Sinne von Reihenfolge spielt keine Rolle Zeit, spielt keine Rolle.
Hier geht es bei den Component Connectors, Structures,
geht es um Interaktion
Und das kann man durchaus auch übersetzen mit Kommunikation. Ja,
und Kommunikation zum Beispiel hier durch in einer serviceorientierten Architektur,
was für Schnittstellen werden dort angeboten, wie arbeiten die Services,
Design by Contract fällt einem da ein.
Also welche Beziehungen, welche Reihenfolgen von Interaktionen passieren hier.
Concurrency Structure ist ja leider ein bisschen abgerutscht,
das Y sollte hier oben
vielleicht noch hingehören
Parallelität, da geht es darum, gemeinsam benutzte Ressourcen.
Auch das spielt in diesen Laufzeitdingen eine wichtige Rolle.
Schreiben wir noch Laufzeit. Laufzeit, Beziehungen. So,
Elocation heißt Zuweisung und da geht es um drei Arten von Zuweisungen.
Die erste Wo läuft ein Element, nicht eine?
Also zum Beispiel, ich habe eine bestimmte Komponente,
eine Laufzeitkomponente, die wird auf dem Webserver laufen,
eine Laufzeitkomponente wird, als Store-Positure in der Datenbank laufen,
irgendetwas wird auf dem Handheld laufen.
Das wird dargestellt mit der Deployment Structure. Die Implementation Structure sagt,
wie wird eine bestimmte Aufgabe, wo wird sie verwirklicht?
Das ist zum Beispiel, dass man dort Worin finde ich
die Realisierung? Und dabei sind häufig Code-Elemente gemeint.
Das passt ja nicht mehr ganz hin,
das fange ich nochmal
ein bisschen vorher an
Also zum Beispiel, welche Pakete sind, für welche Aufgaben zuständig,
welche Code, Quellcode-Dateien sind für welche Sachen zuständig.
Und Work-Assignment, dabei geht es um Arbeitszuweisungen und Arbeitspakete.
Welche Arbeitspakete sind für welche Aufgabe zuständig und diese Arbeitspakete,
das ist das, was der Projektleiter dann braucht, um das zuzuweisen.
Ich gehe mal ganz zurück, als wir Ziele der Softwarearchitektur
benannt haben und hier war so etwas genannt wie, ja hier,
mein inkrementelles Projekt oder Hundelage der Projektplanung, genau das ist das, was der Projektleiter braucht.
Der Projektleiter hat häufig kein tiefes Verständnis davon,
wie die Sachen zusammenhängen, wie das funktioniert,
welche Pattern da drin sind, aber er kann sagen,
okay, wenn er die Informationen bekommt,
das ist ein Arbeitspaket und dieses Arbeitspaket ist weitgehend unabhängig oder es hängt nur von dem und dem ab,
dann kann er entscheiden, ja,
das nehme ich zum Beispiel in die nächste Version oder das gebe ich an einen super Auftragnehmer,
um Zeit zu sparen,
um etwas hinzubekommen oder das ersetze ich jetzt durch etwas,
was ich schon kaufen kann
Soweit zu den Modellen, wie sie von zu den Sichten,
wie sie von Architecture treffen, Design, vorgeschlagen werden.
Die Literatur dazu, für den derjenigen, der interessiert ist,
steht hier, das ist die Literatur von ADT 2.0,
aber die Sichten sind darin erläutert.
Parallel dazu gibt es auch noch andere Dinge,
die in der Industrie verbreitet sind, zum Beispiel hier das sogenannte Siemens 4 Sichten-Modell.
Das kommt daher, dass die Autoren für Siemens gearbeitet haben,
für Siemens Spinston, eine Forschungseinrichtung
Und diese Viersichten sind weitgehend ähnlich oder zum Teil ähnlich zu den Viersichten,
die ich vorhin schon mal gesagt habe,
die man in vielen WoML-Verwandten vorgehensweisen findet.
Also hier gibt es auch zunächst erst mal eine Sicht,
die den Überblick macht. Bei dem anderen hieß es Kontext,
hier heißt es Konzept, dass sie das bitte nicht verwechseln.
Ich schalte mal zu dem Bild, springe mal zu dem
Bild zurück. Als wir hier diese Sichten hatten hier,
genau, Kontext bedeutet das Umfeld.
Während Konzept das Fachliche ist. Also dieses Conceptual Few,
den wir hier hatten, das ist die Fachliche,
die Aufgabensicht
Aufgaben, Anforderungen. Das ist, daraus entwickelt man
die fachliche Architektur oder darin wird die fachliche Architektur dargestellt.
Module View ist wieder die Code,
die statische oder Struktursicht
Execution View, das ist das,
was wir bei dem vorhergehend mit Componite und Connector hatten,
wo es also hier um die Laufzeit ging,
das ist hier auch, das ist hier Execution View,
Laufzeitbeziehungen, Dynamik, also das,
wo es um die Abläufe geht.
Code View ist hier ein Teil des Elocation Views im Vorgehenden,
also hier haben wir, wo die Informationen in welchem Quellcode sind,
finden wir denn die Lösung für welche Aufgabe?
Das entspricht hier dieser Implementation Structure. Deployment Structure in Worgesein
, Minstructure kommt hier in diesen Sichten nicht vor.
Also hier, worin Implementierung? Das ist der Codeview und
die ich hatte gerade von dem Deployment-Führung gesprochen,
der Deployment View ist hier in Ansätzen,
in dieser Deployment Configuration noch mit drin,
wo läuft das Ganze
Cool. Also auch hier würde man in dem Deployment Configuration,
würde man dann sagen, okay,
es gibt hier eine Datenbank, die ja die und die Eigenschaften,
vielleicht auch noch das, was daran läuft.
Die betreffende Literatur ist hier unten angegeben, wo sie etwas dazu finden.
Zusätzlich muss man sagen, es gibt noch spezialisierte Beschreibungsmittel,
die genau das ausdrücken, was eine Architektur braucht.
Nämlich diese Informationen über Strukturen, über Beziehungen und dass man
formale Analysen durchführen kann, formale Analysen für Prüfungen.
Das schreiben wir mit rein für. Zum Beispiel Prüfungen
von Performance-Eigenschaften
Aber auch für die Generierung brauchen wir das. Das ist das,
was wir hier einige Folien vorher dargestellt hatten,
was wir hier möchten als mit formalen Beschreibungen,
Prüfungen ermöglichen, generieren, ermöglichen.
Das haben die vorhergehenden Architekturbeschreibungen eigentlich gar nicht.
Zwei weiter hier, ja. Das ist, das
müsste man hinzufügen. Also wenn wir ein UML-Dia-Kram verwenden,
ein UML-Dia-Kram ist typischerweise immer halbformal und im Sinne von ganz
viel Informationen steckt in den Bezeichnungen.
Das hatten wir hier,
ich springe nochmal zurück
Hier stehen, als semiformal. Ja, ich schreibe das
vielleicht nochmal mit dran. In Bezeichnungen und Semiformal bedeutet also,
dieser Stück ist, dieses Teil ist dann nicht formal,
ohne definierte Syntax und Semantik
Das ist mit semiformal gemeint. Soweit zu den Architekturbeschreibungssprachen im Überblick
. Der letzte Satz sagt ihnen schon, was hier,
was wir über die industrielle Nutzung sagen müssen.
Leider haben sich diese Architekturbeschreibungssprachen in der Industrie nicht so durchsetzen können.
Das hängt damit zusammen, dass ich Spezialwissen brauche,
um sie anzuwenden. Es gibt nur wenige Bereiche,
wo man wirklich damit arbeitet, nämlich insbesondere die,
wo man wirklich die formale Analyse, formale Bewertungen braucht,
wegen besonders hoher Risiken,
besonders hoher Sicherheitsanforderungen.
Da wird tatsächlich mit so etwas gearbeitet
Ich möchte Ihnen Beispiele vorstellen. Zum einen Darwin ADL.
ADL steht immer für Architecture Description Languages. Hier ist es zum Beispiel so,
dass ich, oder ich habe hier einen Ausschnitt gebracht,
der für jede Komponente sagt, Require und Provide,
also die Interface-Beschreibung, die Interface-Beschreibung wird hier so dargestellt,
sodass man am Ende prüfen kann,
ist denn der gesamte komplette Datenfluss da.
Leider ist das hier ein bisschen verschoben,
wo ich das Bild hier habe.
Das ist leider hier beim PDF-Ausdruck
ein bisschen schiefgegangen
Ich hoffe, sie können das dann trotzdem erkennen.
Taylor ist hier der wesentliche. Taylor mit Videovideovic sind hier die Autoren.
Ja, also dieses Darwin ADL ist ein Beispiel dafür,
wie wir mit formalen Mitteln die Interface-Bearbeitung beschreiben und die Zuständigkeiten.
Ja, hier jeweils eine Instanz und die wird gebunden an Werte,
Komponenten mit ihren Schnittstellen, provided required provided.
Dadurch, dass es hier eine richtige Syntax gibt,
kann ich auch prüfen, ist denn das alles bedient,
ist jede Verbindung denn da
Wenn ich das mit der UML mache und hier stehen nur
natürlich sprachliche Ausdrücke dran, die nicht irgendwie definiert sind,
kann ich kaum prüfen, ob die denn das Gleiche sagen.
Wobei wir natürlich auch hier sagen muss,
was wirklich unter Länder Values zu verstehen ist,
ist nur hier unten als Verfeinerung da.
Nicht, was die wirklich bedeuten.
Was will uns der Entwickler damit sagen, der Architekt?
Das bleibt hier letztlich auch nur dem menschlichen Verständnis übrig belassen.
Okay, ein weiteres Beispiel Rapid
Dort geht es darum, dass man Schnittstellen beschreibt, das haben wir hier,
Action, Behavior und da werden wir tatsächlich Werte beschrieben.
Und hier wird dann beschrieben, was passiert dort,
da kann ich wirklich auch Abläufe nachverfolgen, da kann ich
Datenflüsse beschreiben und daraus könnte ich dann auch Code generieren.
Als weitere Darstellung für einen Rapid möchte ich hier etwas darstellen,
dass man dieses Interface, was wir hier haben,
Data Store und die Calculation,
dass wir hierfür auch noch genauer sagen können, was passiert denn da,
was wird denn da getan und dann wird gesagt,
wer ist mit wem verbunden, welche Werte werden wo ausgewertet.
Ich beschreibe hier schon sehr weitgehend, wie die Realisierung aussieht,
wie die Berechnung aussieht, wie die Datenauswertung aussieht.
Es sieht schon fast aus wie eine Programmiersprache,
man könnte das dann umsetzen in eine Programmiersprache,
in unterschiedliche Programmiersprachen und daraus Code generieren
Soweit zwei Beispiele für Architekturbeschreibungssprachen, in gleicher Weise könnte man jetzt hier,
oder gibt es auch Sprachen,
die dann hier mit Syntax und Semantik etwas dazu sagen,
wie das Zeitverhalten ist.
Also wie lang dauert eine Operation? Und dann kann ich
aus der Kette der Operationen und der Dauer minimal, maximal berechnen,
ob ich innerhalb eines bestimmten Zeitvorrats bleibe oder ob es mir reicht,
ob die Performance die Ressourcen reichen, eine bestimmte Häufigkeit von Ereignissen zu berechnen.
Die Fragen dazu waren ja, bezogen sich auf die UML,
deswegen möchte ich, ich springe einmal noch zu der Frage
zurück und möchte noch kurz etwas zu den UML-Diakrammen dazu sagen.
Also hier war die Frage, wie sollte die Beschreibung einer Softwarearchitektur
aufgebaut sein und welche Diagramme Geld eignen sich für Architektursichten,
das schreibe ich hier mal an die Diagramme dran.
Also wir haben hier, einerseits hatten wir auf Folie 8,
das schon mal mit den Diagrammen dargestellt, ja,
also die Kontextsicht, die Struktursicht, verhaltenssicht und die Abbildung sich,
damit war das eigentlich schon ganz komplett, was hier noch fehlt,
ist die fachliche Sicht, das füge ich mal hinzu,
Zu der Darstellung mit den Siemens-Sichten.
Und ich packe das mal hier oben hin und nehme mal hier Grün,
damit wir das noch ein bisschen anders sieht.
Also zunächst, Pakete eignen sich immer, um Zusammenhänge darzustellen.
Das wäre erst mal das Package-Deierkampf. Dann kann man natürlich
Use Cases angeben
Dann haben wir statische Beziehungen, das könnte man mit dem
Komponentendiagramm darstellen. Ups, da ist mir was abgehauen.
Bei diesen Struktur zu den Struktursichten Gehört zum Beispiel auch Datinstrukturen.
Und dann haben wir natürlich noch die ganzen Interaktionsdiagramme,
zum Beispiel Aktivitätsdiagramm, Aktivity, da sollte man dann MC schreiben,
Um auch das Verhalten darzustellen, weil auch im Fachlichen gibt es Verhalten,
da gibt es Workflows, da gibt es Rollen und Zustände,
zum Beispiel Zustand eines Flugtickets, Zustand einer Zollabfertigung oder so etwas.
Auch das muss man darstellen. Und diese, die Diagramme
eignen sich dann jeweils ebenfalls für die Funty konzeptionelle Sicht.
Für die anderen Sichten hatten wir hier schon welche. So,
damit hätten wir die Fragen, ach so,
und vielleicht nur, dass wir einen Blick drauf werfen,
alles, was wir hier haben,
hatten wir in dem eben genannten Sichten schon dargestellt,
Workassignment, das war Folie 5 schon mit diskutiert,
nämlich diese Arbeitspakete, Implementations, Tructure, Elemente,
da gibt es das Paketdiagramm und strukturellen und Verhaltensdarstellungen waren in dem Fully 5 auch schon mit dargestellt.
Damit hätten wir die Frage hier beantwortet und sind diese Frage
8 beantwortet und sind damit am Ende dieses Abschnitts.
Vielen Dank