Im Abschnitt 7.3 möchte ich den Begriff der fachlichen Architektur einführen.
Wie ich schon anfangs sagte, geht es in diesem ganzen Kapitel 7,
wie auch in dieser Lehrveranstaltung, weniger um den Entwurf an sich.
Der spielt natürlich eine Rolle, aber es geht uns vor allen Dingen darum,
welche Modellierungssprachen wir einsetzen, wie man Modellierung macht.
Und deswegen dieser spezielle Abschnitt fachliche Architektur ist schon etwas
ein bisschen was anderes als das Technische.
Deswegen fangen wir damit an. Die Frage,
die wir dazu hier in den Wiederholungsfragen sehen,
wozu wird eine fachliche Architektur benötigt, zielt genau auf diesen Begriff.
Wir haben, wir starten damit,
dass wir uns das vielleicht erstmal mit dem Hinweis,
dass wir uns im Buch auf die Abschnitte 5,
6 und 6, 1 beziehen.
Werden wir doch zu den vergangenen Abschnitten nicht so sehr viel hatten,
ist es hier dieser Abschnitt der 5, ja,
die spielen hier eine größere Rolle.
Ich habe, gefangen, starte hier mal mit einem Bild aus
dem Kapitel 6-2. Ich hoffe, das ist sogar richtig.
Ja, genau. Das habe ich vorgezogen,
um mal zu zeigen, was ist denn das hier?
Das ist hier die technische Architektur. Ja, also das steht jetzt
hier oben. Ja, also die schicktechnische Architektur sind drei Schichten.
Sie erinnern sich, hatte ich schon mal erwähnt, wenn nicht,
sage ich es jetzt, dieses Slimline ist ein Beispiel aus unserem Buch.
Da geht es darum,
dass man ein Hausautomationssystem verwendet oder bauen möchte beschreiben möchte,
da geht es um intelligente Steuerungen der Funktionen,
die man so in einem Gebäude hat, über Licht,
Warnung vor Einbruchbruch oder Gefahren bis zur Steuerung von netten Sachen.
Also das E-Aquarium immer gut gefüttert und gereinigt wird,
wenn es denn über Computersteuerung möglich sei.
So, also die technische Architektur, es zeigt dieses Bild,
sind hier drei solche Kästen. Sie sollten jetzt erkennen können,
so ein Kasten mit so einem Reiter obendran,
was das für ein Element ist
Das können wir ja gerne nochmal diskutieren. Das ist ein Diagramm
der UML, so wie verrate ich Ihnen schon mal.
Und wir diskutieren das dann in der Frage Antwort-Session.
Also das zeigt uns, dass wir drei Schichten haben,
die Hardware-Treiber als unterste Schicht, weil techniknah dann die Komponenten,
die irgendwie diese fachlichen Dienste darstellen und Applikationen als etwas,
wo man vermutet, dass der Mensch damit arbeitet.
App hat sich ja der Begriff App hat sich ja schon
total etabliert über die Mobilfunkapplikationen,
auf Mobilgeräten
Applikationen. Ja, soweit erstmal die fachliche,
die technische Architektur auf diesem Bild, ja,
und jetzt möchte ich etwas dazu sagen,
wozu brauchen wir denn jetzt eine fachliche Architektur?
Zunächst brauchen wir dazu erstmal ein leeres Blatt,
das muss ich mir hier auch einfügen und ich möchte kurz erläutern,
was eine technisch, eine fachliche Architektur, denn ist,
wozu wir die denn brauchen?
Wir müssen, wenn wir ein System entwerfen, eine Struktur entwickeln,
Struktur brauchen wir deswegen weil wir die Teile voneinander abgrenzen wollen.
Die Systeme, die so groß sind,
dass wir eine Architektur davon brauchen oder für die Entwicklung brauchen,
die sind zu groß, um sie im Ganzen darzustellen,
um sie im Ganzen zu verstehen, um sie im Ganzen prüfen zu können.
Deswegen teilen wir sie in kleine Teile, die Komposition,
Zerlegung auf Deutsch. Und diese Zerlegung in Teile,
das ist eine wichtige Aufgabe, die man während der Entwicklung
während des Entwurfs durchführt.
Und das ist das,
was wir hier brauchen
Die Architektur ist noch mehr,
aber für uns ist sie erstmal eine Gliederung der Lösung.
Und damit ist es eine Zerlegung in Teile. Außerdem brauchen
wir, treffen wir Entscheidungen zur Realisierung. Wie setzen wir
die Aufgaben um? Und diese Realisierung bezieht sich immer auf Aufgaben,
über Diese Zerlegung in Teile, häufig sind das,
bezeichnen das als Komponenten, die brauchen wir bei der nächsten Frage auch wieder.
Entscheidung über die Realisierung von Aufgaben durch Komponenten.
Und das bezeichnen wir als Zuweisung von Verantwortlichkeiten
Diese Entscheidung, die über die Zuweisungen und Verantwortlichkeiten bedeutet,
dass ich, nachdem ich bei dem ersten Punkt hier Boxen gemacht habe,
sozusagen Kästchen, schreibe ich hier dran,
was die Kästchen denn tun.
Ja, also eigentlich gar nichts Besonderes. Und diese Entscheidung,
diese Zuweisung, die machen wir ganz stark nach den Aufgaben.
Und diese Aufgaben, das sind Sachen,
hier heißen sie Verantwortlichkeiten, das sind Dinge,
die fachliche Aufgaben darstellen
Deswegen nennen wir das Ganze in dem ersten Schritt
fachliche Architektur, weil wir fachliche Aufgaben zuweisen.
Fachliche Aufgaben werden zerlegt in ihrer Bestandteile.
Sie werden gruppiert zu Bausteinen
Sprechen wir mal damit, dass jetzt, zerlegte Aufgaben sind,
also die wollen wir dann gruppieren und dann Module bilden,
die gut zusammengehören.
Das ist ein wichtiger Baustein dieses Schrittes. Und jetzt können
Sie schon ahnen, worauf der Dozent jetzt hinaus will,
nämlich das,
was wir bei Modularität
alles gelernt haben
Dinge, die zusammengehören, sollen hier zusammenkommen,
also so ein Modul soll Zusammengehörige Dinge umfassen.
Ja, also Modularität, das ist gekennzeichnet durch Entkopplung von anderen.
Wir haben den Begriff hohe Koalition,
auf jeden Fall alles schon mal gehört,
Kuhision heißt der Zusammenhalt, also fester innerer Zusammenhalt,
innerhalb Entkopplung von anderen.
Das ist wichtig für Modularität
Und das wollen wir erreichen, indem wir Dinge gruppieren,
die vielen miteinander zu tun haben.
Das ist etwas, was man beim Entwurf machen muss,
wie wir da genau, wie man das genau macht.
Da gibt es unterschiedliche Möglichkeiten. Im Moment ist gerade Domain
driven Design so ein bisschen ein Hype, ein Schlagwort,
wo die Leute damit, um sich gerne umherwerfen,
in den 90ern, war das objektorientierter Entwurf,
in den 80ern war es strukturierter Entwurf.
Die Prinzipien sind aber
sehr stark ähnlich
Immer zusammengehörige Sachen finden, die wir zusammen,
die wir gruppieren und zusammengehörig sind, welche,
die viel miteinander zu tun haben.
Ja, und das sollen Module, Module sein. Ja,
und jetzt ist die Frage, was wollen wir mit dem Modell?
Was kann uns das Modell dabei helfen?
Die Modellierung soll diese Architekturentwicklung unterstützen, Indem sie uns hilft,
diese Inhalte, die zu Sachen darzustellen.
Also zunächst erstmal muss sie diese Bausteine, die wir hier bilden wollen.
Ja, also diese Komponenten, diese Teile,
diese Module muss ich erstmal darstellen.
Das heißt, zunächst brauchen wir erstmal die Darstellung von Blöcken
Ja, das ist in irgendeiner Form Blöcke oder Komponenten
können wir da durchaus das so bezeichnen.
So, das ist einwächtiger Punkt. Dann diese ganzen Teile
müssen in irgendeiner Form zusammenarbeiten. Deswegen brauchen die Dinger Schnittstellen
über die Schnittstellen sollen sie ja miteinander interagieren, ja,
aber bitte eine lose Kopplung nur haben,
diese Entkopplung.
Das passiert über die Gestaltung der Schnittstellen
Die Dinge haben noch mehr miteinander zu tun,
als nur über die Schnittstellendaten auszutauschen.
Die haben Abhängigkeiten voneinander. Diese Abhängigkeiten,
zum Beispiel das eine benutzt Ressourcen des anderen, das eine importiert etwas anderes.
Das eine folgt nach einem anderen oder so etwas.
Diese Abhängigkeiten sind wichtig zum Verstehen, damit wir die Aufgabenstellung darstellen.
Und natürlich haben diese Dinge auch eine Semantik.
Das heißt,
sie tun etwas
Und die Semantik wollen wir auch darstellen. Nun können Sie
schon auf dem, was wir von UML gelernt haben,
können Sie schon ahnen, dass wir relativ,
dass es uns nicht schwerfallen wird, Blöcke und Komponenten darzustellen.
Dazu hatten wir das Komponentendiagramm. Ja, wunderbar,
das Komponentendiagramm konnte auch Schnittstellen darstellen und auch Abhängigkeiten.
Aber wenn Sie überlegen, wie dort Semantik dargestellt wird,
dann wird Ihnen nicht viel einfallen, was grafische Elemente betrifft.
Es gab zwar einen Vorrat an grafischen Elementen und vielleicht kann ich
bei einer Schnittstelle noch sagen, rein raus und synchron,
asynchron oder irgend sowas, aber die wirkliche Bedeutung,
Und zwar über Begriffe, über natürliche Sprache.
Und das ist das, was wir hier durchaus auch nur benutzen.
Diese Begriffe in natürlicher Sprache, das sind die Begriffe,
die am Ende genutzt werden, um die Semantik auszudrücken.
Und das sind auch die, die wir brauchen,
um hier als, das wollte ich jetzt nicht,
ich wollte hier nicht drin rummalen,
dann sind wir
das wieder wegbekommen
Das sind nicht die Sachen, die wir hier brauchen,
um hohe Koessionen zu erreichen, sondern wir müssen versuchen,
solche Sachen zu finden, die zusammengehören.
Und das können wir durchaus machen,
indem wir hier Techniken einsetzen zur Sprachverarbeitung.
Also können wir hier Cluster zum Beispiel analysieren? Nein,
das schreibe ich auf die nächste Folie,
die Nutzung dieser Modelle.
Dann nehmen wir mal
ein neues Platt hier
Querformat. Nutzung dieser Modelle, die wir eben hatten, bei Entwicklung einer fachlichen Architektur
Vielleicht sollte man das auf der vorgehenden Seite auch mal unterstreichen.
Ja, hier haben wir den Begriff Architektur. Und das Unterstützen.
So, und jetzt, wie sieht es denn aus,
diese Unterstützung? Zum einen Verständnis von Zusammenhängen, Vermitteln.
Das ist vor allen Dingen hier, dass wir sagen, welche Blöcke sind das?
Welche Schnittstellen sind das? Wie hängen die ganzen Sachen zusammen? Dann,
dass gute Module finden, da könnte man zum Beispiel,
natürlich können sie das immer als Menschen mithilfe ihres Intellekts machen,
aber man kann tatsächlich auch Werkzeuge benutzen,
die diese Begriffe, die wir hier haben zur Semantik,
dass man die auswerten,
das wäre zum Beispiel Eine Cluster-Analyse.
Und diese Begriffe, die wir da verwenden,
sind Medul, Bezeichnungen, Begriffe der Anforderungsbeschreibung
Das könnten wir analysieren, um daraus zusammenhängende Zusammenhänge zu finden.
Und das wäre dann so etwas, was wir hier mit
Modulbilden machen wollen, die dann eine hohe Kollision haben.
Also diese Begriffe natürlicher Sprache dann finden.
Was damit eng zusammenhängt, Bezüge zu den Anforderungen herstellen,
Herstellen, das schreiben wir ein bisschen schöner noch.
Herstellen oder wenn Sie wollen, auch darstellen,
das wäre diese Verantwortlichkeiten.
Indem wir Begriffe aus der Anforderungsbeschreibung
als Modulbezeichnung verwenden
Oder in Modulbezeichnungen verwenden. So, damit haben wir
es schon ein ganzes Stück weit ein Modell entwickelt,
ein Modell, was zunächst erstmal Komponenten enthält.
Ja, diese Komponenten, ob wir die jetzt Teile,
Komponenten oder Module bezahlen, hängt ein bisschen davon ab,
in welcher Modellierungsmethode wir jetzt unterwegs sind.
Aber die sollen auf jeden Fall über Schnittstellen miteinander zusammenhängen.
Die Abhängigkeiten, sie bekannt sind, sollen dargestellt sein.
Und die Semantik soll so beschrieben sein,
dass wir daraus Zusammenhänge erkennen können, Blöcke bilden können,
die viel miteinander zu tun haben.
Und gleichzeitig auch diesen Bezug zu den Anforderungen herstellen über diese Begriffe.
Und das wäre diese Zuweisung Fun Verantwortlichkeiten.
Vielleicht schreiben wir das noch mit davor.
Das hat mir
eben schon irgendwo
Zuweisung von Verantwortlichkeiten. So, wir haben hier ein paar Bilder,
die wir aus dem Buch übernommen haben. Ich möchte sie dann mit,
die möchte ich kurz mit ihnen besprechen, damit sie damit ermutigen,
durchaus noch was weiter mit dem Buch zu arbeiten.
Wir beziehen uns hier auf das Bild der technischen Architektur, dass ich ihnen schon gezeigt hatte. Ja,
also es gibt hier die Schicht Applikationen,
das sind die Sachen, die eine Nutzerschnittstelle haben,
dass die Schicht Komponenten, die zweite technische Schicht,
die so etwas wie Dienste zur Verfügung stellt und eine Schicht Hardware-Treiber,
die dann wirklich auf Geräte, Steuereinheiten oder sowas zugreift.
Ja, und wir schauen uns zunächst erstmal an,
wie die fachliche Gliederung auf dieser obersten Ebene der Applikationen,
Applikationsebene aussieht, ja, also diese Ebene könnte so sein,
dass wir das Softwaresystem aus drei Teilen besteht,
und zwar ein Teil, der sich mit einem Bruchschutz beschäftigt,
ein Teil mit Wohnklima und ein Teil mit Unwetterschutz.
Diese drei Teile sind, enthalten jeweils weitere Teile. Ja,
das ist jetzt hier in diesem Bild nicht dargestellt,
aber sie stellen jeweils hier eine Gruppe dar,
eine Gruppe von Sachen, die zusammengehören. Ich hoffe,
sie können sich genügend, haben genügend Fantasie, sich vorzustellen,
was man zu einem System für ein modernes Haus alles haben kann,
aber sie können sich auf jeden Fall unter dem Begriff Einbruchsschutz etwas vorstellen.
Da gibt es vielleicht eine Überwachung, dass die Türen abgeschlossen sind.
Da gibt es eine Überwachung von Räumen, die keiner wird,
nur wo normalerweise es keiner sein kann, mit einem Bewegungsmelder,
da gibt es Überwachung von Fenstern und Türen, ob die vielleicht aufgeknackt werden
Vielleicht gibt es noch Überwachung des Außenraums, ob sich da jemand bewegt,
zu Zeiten, wo man es nicht erwartet.
Ja, also mehrere Sachen, die zusammengefasst sind, weil sie zusammengehören.
Fachlich zusammengehörende Sachen, die zum Beispiel vielleicht alle irgendwas,
wir hatten gerade von Begriffsanalyse getut,
vielleicht gibt es dort eine ganze Reihe von Applikationen,
die irgendwie mit Schutz zu tun haben.
Nun gibt es hier auch nur Schutz, aber hier irgendwie
Schutz mit etwas Bösem, was andere Menschen einem antun wollen vielleicht.
Bleiben wir, gehen wir gleich mal zu dem Punkt,
auch Schutz, ja,
aber Schutz vor Naturereignissen
Naturereignisse können zum Beispiel sein Sturm, große Hitze,
Flut, so etwas könnte hier als Unwetter,
dafür könnte gewandt werden, da können wir entsprechende Sensoren haben.
Und da die Überwachung, das könnte,
wir können uns jetzt ein bisschen weiter zusammenspinnen, können wir sagen,
okay, da könnte man vielleicht den Wetterbericht noch einblenden.
Ich weiß nicht, ob das zu dieser Applikation dazugehört.
Schauen Sie im Buch mal nach, was da noch alles,
was da noch alles dazu kommt.
Ich glaube, so super viele Details stehen da nicht mehr.
Für uns ist wichtig, was drückt das Modell aus?
Das Modell zeigt hier
einen Kasten
Ein Kasten mit dem UML-Stereotyp-Applikationen. Ja, also der Kasten
steht nicht für eine Klasse. Der steht für eine Applikation.
Und das ist eine Sammlung von, ist ein Block,
eine Einheit mit der Verantwortlichkeiten für eine ganze Reihe von Aufgaben dazu.
Zeigung. Wir haben hier noch eine dritte, eine dritte Applikation,
wo es um Wohnklima geht. Sie können sich also damit ausdenken,
dass es vielleicht auf jeden Fall um Heizung oder Kühlung geht,
dass es vielleicht um Feuchtigkeit geht, vielleicht auch noch Schutz vor
Zu übermäßiger Sonneneinstrahlung, dass man also auch irgendwie Steuerungen im Hause tut.
Aber man kann schon, aus der Darstellung hier von dem,
was sie sich darunter vorstellen, vermuten, ja,
das ist recht gut getrennt von dem und dem.
Die haben bestimmt was miteinander zu tun, weil es gibt ein paar Sensoren,
die vielleicht in mehreren dieser Applikationen ausgewertet werden,
aber sie haben erstmal, es ist eine Trennung voneinander.
Also das ist die oberste Ebene, Applikationen,
die wir hier gesehen haben, oben. Das nächste Bild,
was wir auch aus dem Buch übernehmen,
zeigt uns die Ebene Komponenten, ja, auch die fachliche Gliederung wiederum,
aber von diesen Komponentenebene und dass diese Komponenten,
das waren Sachen, die, so sagte ich das,
die man hier in diesem System so gedacht hat,
als sie liefern Dienste.
Sie werten vielleicht etwas von der darunter liegenden Hardware-Ebene aus.
Also für Glasbruch, da gibt es alle möglichen Formen von Glasbruch,
Meldern. Das haben Sie vielleicht schon mal gehört,
es gibt welche, die dann den Ultraschall aufnehmen,
der knirschendes Glas so verklöschendes Glas typisch ist oder es gibt welche,
die dann an dem Glas selber aufgeklebt sind und dann so Mikrorisse mit oder Risse mitkriegen.
All solche Sachen können für Glasbruch als Melder gedienen und die
sind wahrscheinlich dann, liefern Signale für die Einbruch,
für den einen Bruchschutz
Sturmerkennung hat auf jeden Fall sowas mit Windbewegungen zu tun und Regenerkennung,
was mit einer Niederschlagserkennung. Ja, und das sind jeweils Komponenten.
Wir sehen hier jeweils einen Kasten mit dem Stereotyp Komponente.
Und diese Komponenten sind jeweils Teile des Subsystems. Softwaresystem,
also ein Teil unseres Systems, aber eben auf der
zweiten Schicht, auf der Schicht der Komponenten.
So, soweit, soweit erstmal nur dargestellt, ja,
wir haben hier Komponenten gebildet, die haben Beziehungen miteinander.
Es ist jetzt nicht dargestellt, dass das Regen mit den Unwetter
zu tun hat und das Glasbuch mit dem Einbruch und die Sturm, ja,
gehört das zum Einbruch oder das ist ja nicht dargestellt.
Tatsächlich brauchen wir noch viele mehr Diagramme, weil wir wollen alle Informationen,
die wir im Zusammenhang mit dieser Zuweisung von Verantwortlichkeiten haben,
die wollen wir alle gern in Modellen darstellen,
dass diese Modelle diese Informationen vollständig erfassen.
Und was wir dazu brauchen, sind Modelle,
Modellierungssprachen,
die so etwas ermöglichen
Soweit zu dem, was wir bei fachlicher Modellierung brauchen.
Wir haben, bitte, bemerken Sie das, kaum technische Sachverhalte hier genannt.
Also wir haben nirgendwo gesagt, mit was für Datentypen wird das implementiert,
mit welcher Technik, wie wird wie die Putti-Parameter-Übergabe gemacht?
Wie werden Signale erkannt oder übertragen? All diese Sachen,
die technische Entscheidungen umfassen, sind erstmal nicht dabei, sondern das,
was wir hier gesagt haben, sind erstmal alles Sachen,
die wir aus der Aufgabenstellung ablesen können, die wir ermitteln,
indem wir das System verstehen und dann verstehen,
was für unterschiedene Teile, Teilaufgaben es denn hier gibt,
abgrenzbare Teilaufgaben.
Natürlich gestalten wir dabei auch das System, in dem wir sagen,
ja, wir machen da eine Applikation,
Einbruchsschutz und nicht zeigen nur 200 Sensoren und der Mensch muss dann schauen,
wie er damit zurechtkommt.
Das war der Abschnitt
fachliche Architektur