Im letzten Abschnitt dieses Kapitels haben wir wieder Architektur im Titel.
Und hier geht es uns darum, zu sagen,
welche technischen Entscheidungen können wir durch Modelle beschreiben.
Zunächst müssen wir erst mal sagen, ja,
wir bewegen uns im Engineering in den Ingenieurwissenschaften,
wo es darum geht, etablierte Lösungen zu sammeln,
diese Lösungen aufzubereiten, anzupassen, wieder zu verwenden.
Also keiner würde eine Schraube oder ein Kugellager neu entwickeln.
Und genauso sollten wir davon abkommen,
dass wir Treiber und Konvertierungsprogramme immer wieder schreiben,
sondern wir versuchen,
Verallgemeinerungen zu finden
Diese Verallgemeinerungen sind zum Teil natürlich auch Quellcode in Form von Bausteinen,
aber ganz viel verallgemeinerte Lösungen, die man noch anpassen kann,
aber die für eine ganze Klasse von Anwendungen passen,
wie eben Entwurfsmuster, also Design-Patterns oder Lösungsprinzipien.
Wir hatten vorhin diese Entwurfsprinzipien besprochen. Und Bibliotheken fassen manchmal
solche Bausteine zusammen, aber auch Werkzeuge, Technologien,
die kommerziell angeboten sind, gehören hier dazu.
Die schreibt man nicht immer neu. Komm, einer wurde
auf die Idee kommen, eine Datenbank neu zu entwickeln.
Dafür gibt es Produkte. Das Gleiche trifft zu auf Sicherheitslösungen
oder so etwas
Außerdem gehört zum Engineering, dass man versucht, systematisch zu entwickeln.
Systematisch im Sinne von, ich möchte einen wiederholbaren Weg gehen.
Dieser wiederholbare Weg ermöglicht es uns auch, Vorhersagen zu machen.
Der widerhoseure Weg ermöglicht es uns, Vorhersagen zu machen,
wie gut denn die Produkte sein können.
Wir können einerseits sagen, ja, wir werden diese Qualitätsziele erreichen.
Zum Beispiel, wir werden diese Performance erreichen,
auch wenn wir im Moment das noch nicht abschätzen können,
weil noch nichts Laufweges da ist. Aber wir treffen Entscheidungen zu sagen,
wenn wir das Fremdwork verwenden und wenn wir diese Struktur verwenden
und dort mit Cues und asynchroner Verarbeitung dafür sorgen,
dass wir eine Pufferung haben,
dann werden wir in so einer Antwortzeit ungefähr landen.
Und diese Analyse der Ziele ist die Voraussetzung dafür,
dass wir also die Anforderungen verstehen,
dass wir frühzeitig prüfen und dass wir auch,
falls etwas nicht funktioniert, wir iterativ uns verbessern.
Das ist in diesem systematischen Entwicklungsprozess,
das ist entweder eine Berufsmethoden drin, also hier,
ich schreibe einfach mal dran,
dass hier
Entwurfsmethoden eingesetzt werden
Ich hatte ja hier zum Beispiel die Methode EDD genannt,
Domain Treffen Design war bei fachlicher Architektur auch mal.
Also das sind, das sind Methoden, die man verwendet,
um auch ein Team gemeinsam arbeiten lassen zu können.
Da muss ich etwas haben, was sich andere lehren kann,
wo sie etwas nachlesen können und das in solchen,
in solchen Methoden dann zusammengefasst.
Hinzu kommt noch, dass wir zielorientiert entwickeln,
dass wir uns also danach orientieren, was für Ziele hat der Auftraggeber.
Und dazu gehört natürlich auch, dass wir messen können,
wie weit wir sind
Und dieses Messen basiert auf den Entscheidungen, die wir getroffen haben.
Also wir haben hier Entscheidungen getroffen, zum Beispiel über technische Lösungen.
Und die Entscheidungen führen dazu, dass wir schon Eigenschaften...
Von technischen Lösungen festgelegt haben. Wir haben festgelegt,
wir benutzen dies und jenes Framework als Mittelwert zur Weitergabe
oder in einem serviceorientierten System zur Verteilung der Services
Als Poker oder sowas. So eine Architektur.
Und damit haben wir schon festgelegt, ja,
diese Poker-Architektur hat ein paar bestimmte Eigenschaften.
Und diese Eigenschaften können wir dann einfließen lassen in die Prognose
der Gesamteigenschaften des Gesamtsystems.
Ja, und diese Eigenschaften dann messen aufgrund Verhersage der Eigenschaften
aufgrund der entschiedenen technischen Lösungen
Und das ist auch schon dieser wesentliche Unterschied zwischen der Phase der technischen Architekturentwicklung unter fachlichen Architekturentwicklung.
Bei ein paar Sachen gibt es bei beiden, nämlich,
dass ich Komponenten bilde, die Kommunenten haben ihre Verantwortlichkeiten,
die Komponenten haben in irgendeiner Form Zusammenhänge,
aber hier treffe ich technische Entscheidungen und diese Entscheidungen führen dazu,
dass ich bestimmte Lösungen schon mal sicher habe,
bestimmte Eigenschaften sicher habe.
Also ich habe laufend für ein Performance gesprochen,
weil es eines der wichtigsten Qualitätsziele ist.
Sicherheit spielt genauso die Rolle wie Zuverlässigkeit. Ja,
ich habe dann für bestimmte Redundanz schon gesorgt und die Redundanz ist etwas,
was ich dann einbeziehen kann in die Vorhersage,
wie wird sich denn
dieses Ausfallverhalten des Gesamtsystems entwickeln
Ja, und deswegen,
das ist auch genau der Punkt hier und steht es noch mit Fragezeichen,
wo uns Modelle helfen, nämlich diese,
ihr sollt entschiedenen technischen Eigenschaften stehen, dass die Eigenschaft,
diese technischen Lösungen,
die Eigenschaften haben und diese Eigenschaften werden in Modellen festgelegt.
Also hier und deren Eigenschaften
Eigenschaften ist ja natürlich so ganz allgemein das Funktionale,
die Qualitätseigenschaften, all diese Sachen werden in den Modellen festgehalten.
Und das ist das, was wir hier brauchen.
Die Modelle haben wir alle schon besprochen in den vorgehenden Einheiten.
Ich kann gerne noch mal dahin zurückspringen. Ja,
wir hatten hier die Sichten, die also etwas darstellen.
Und natürlich können wir hier, wo wir gesagt haben,
ja, die verhalten sich, ja,
da haben wir die Reihenfolge der Nachrichtenaustausch, aber eben können,
da können wir auch technische Eigenschaften reinschreiben oder Qualitätseigenschaften durch Annotationen oder sowas unterbringen.
Wie ist denn das Zeitverhalten? Tatsächlich gibt es eine UML
sogar in Diagramm, was das Zeitverhalten beschreibt.
Timing-Diagramm, nur um das mal genannt zu haben,
verwenden wir, behandeln wir in dieser Lehrveranstaltung nicht.
Das war irgendwo bei den UML-Diagrammen mal mit dabei. Soweit zu dem,
was wir erst mal grundsätzlich bei einer technischen Architektur machen.
Ich möchte auf den Begriff Referenzarchitektur bekommen, weil wir das,
weil es eine solche wiederverwendbare Lösung ist,
die wir hier haben, also so eine erfolgreiche Lösung wiederverwenden.
Das gibt es nicht nur auf dieser Ebene Entwurfsprinzip, ein Entwurfsmuster,
sondern auch noch eine Ebene höher, eine Ebene abstrakter Referenzarchitektur.
Die Frage, die wir zu die Wiederholungsfrage,
die wir ganz vorne haben, fragt genau danach,
was ist eine Referenzarchitektur?
Deswegen darf ich Ihnen das nicht vorenthalten. Eine Referenzarchitektur ist
die verallgemeinerte Lösung. Ich schreibe das mal hier oben,
hier ist ein bisschen Platz frei.
Da packe ich das mal mit rein
Und zwar eine verallgemeinerte Architektur, die für eine bestimmte Ebene,
für eine bestimmte Domäne... Vorgesehen ist und dafür gute Eigenschaften hat.
Ich stelle jetzt hier gleich zwei, drei solche Domänen oder
solche Referenzarchitekturen vor. Man sagt dazu auch manchmal Blueprint,
im Sinne von Blueprint ist immer die technische Zeichnung für den
Bau von irgendetwas.
Also das Baumuster
Sowas haben Sie schon ähnlich bei Programmierung auch gehört,
wo man sagt, okay, die Klasse und das Interface,
die bittet in gewisser Weise das Baumus dafür,
Objekte oder für ihr Schnittstellen vor.
Hier ist es noch eine ganze Ebene allgemeiner. Es gibt grundsätzliche Blöcke von Aufgaben,
die man hier in Blöcken vorsieht. Dann sagt man,
bei jeder Architektur für das und das Gebiet ist das so ähnlich.
Das ist so ein bisschen eine Kurzform der Beschreibung,
was Referenzarchitektur ist. Dazu gehört, dass ähnliche Lösungen,
ähnliche Entscheidungen getroffen werden, Ähnliche, grundlegende Aufgaben.
Ähnliche Entscheidungen über grundsätzliche Entwurfsentscheidungen. Da soweit zur Beschreibung des Begriffs
eine ganze feste Definition des Begriffs möchte ich Ihnen hier nicht anführen,
weil es zu viele unterschiedliche gibt.
Ich denke, das reicht soweit, dass wir wissen,
verallgemeinert ist Es gibt ein paar Gemeinsamkeiten, die für eine ganze Domäne zutreffen.
Und die Beispiele jetzt sollen ihnen ein bisschen umreißen,
was mit dem Begriff Domäne gemeint ist. Domäne,
der Begriff kommt eigentlich daher, dass ich für ein Herrschaftsgebiet
die Domäne eines Fürsten oder ein verliehenes Landgebiet, ein Lehen im Feudalismus.
Dafür wurde dieser Begriff gebildet und wir haben heute den Begriff
Domäne für ein Anwendungsgebiet häufig.
Ich möchte jetzt hier verschiedene Referenzarchitekturen vorgeben. Hier,
wir starten mal mit einer ganz einfachen IFA-Eingabe,
Verarbeitung,
Das ist doch falsch, das muss doch EVA heißen.
Das müssen wir jetzt hier mal korrigieren. EVA heißt das Ding.
Eingabeverarbeitung, Ausgabe, netter, netter Taipo. Sieht so aus,
dass ich, das stammt noch aus der Zeit der Batch-Programmierung,
dass ich also meine Eingabe hatte über irgendetwas,
damals vielleicht noch Lochkarten, ja, so in was in der Art,
dann wird es eine Batch-Verarbeitung durchgeführt und dann gab es in irgendeiner Form eine Ausgabe.
Und diese Batch-Verarbeitung, die griff natürlich irgendwie auf Datenspeicher zu
Ja, das war so die grundlegende prinzipielle Struktur und diese Struktur gibt es in ganz vielen Dingen,
wo Verarbeitung ohne direkte Interaktion und interaktive Systeme passiert,
wo ich also Streams verarbeite, wo ich große Datenmengen verarbeite.
Da wird dieses Schema immer angewendet und das hat natürlich bestimmte Annahmen oder Vorgaben,
wie Schnittstellen aussehen, weil ich eben nicht zwischendurch interaktiv irgendwo drauf warte.
Das nächste stammt aus unserem Buch,
da gibt es ja ganz viele Sachen zu eingebetteten Architekturen,
die wir hier in unserer Lehrveranstaltung irgendwie ein bisschen weglassen,
ein bisschen unterdrücken und dieses,
diese eingebettete Struktur folgt tatsächlich auch so ein bisschen dieser Eingabeverarbeitung, Ausgabestruktur.
Wir haben Eingabe von irgendwelchen realen Werten,
also hier ist ein elektrisches Symbol für einen Taster,
für einen Schaltkontakt angegeben, vielleicht einen Schaltkontakt.
Der Fahrstuhl hat die fünfte Etage erreicht. Hier ist dann
für ein kontinuierliches Signal, also zum Beispiel ein Temperaturmessung,
ach ne, das Temperaturmessung, das richtige elektrische Symbol ist hier.
Hier könnte zum Beispiel eine Drehwinkelmessung sein oder eine Belastungsmessung durch ein Sensormessstreifen,
durch ein Dähnmessstreifen, durch änderliche Dehnung,
wird der Widerstand verändert und der wird dann abgetastet.
Und das kann dann gefiltert vorverarbeitet, bewertet werden. Das ist die Eingabe sozusagen,
dass wenn man die Sensoren mit dazu nimmt, ist die Eingabe,
dann kommt die Verarbeitung, die Verarbeitung hier in dem Fall,
könnte man von Ereignissen machen oder nein, von Zeiten.
Und dann gibt es die Ausgaben, wo Akteure, Aktoren passieren.
Also hier ist dargestellt, das elektrische Symbol eines Motors,
das elektrische Symbol einer Leuchtdiode,
als Lichtausgabe oder hier eines Ventils,
was gesteuert wird für ein Flüssigkeits- oder Gasstrom
Ja, also auch hier Verarbeitung, Eingabeverarbeitung, Ausgabe,
das Ganze ganz häufig Zeit oder Event gesteuert.
Mehr dazu finden Sie im Buch 5,
5. Wir behandeln in dieser Lehrveranstaltung nicht mehr dazu,
nur dass Sie wissen, wenn Sie damit mal zu tun haben,
von wegen, ja, ich weiß ja noch gar nichts.
Ja, Sie wissen immerhin Verarbeitung, Eingabeverarbeitung, Ausgabe ist das grundlegende Prinzip.
Weitere Referenzarchitekturen hier aufgelistet, so möchte ich die Versicherungsanwendungsarchitektur VAA nennen.
Die ist von einem großen Konsortium großer Versicherungen in Deutschland entwickelt
worden, im Gesamtverband der deutschen Versicherungswirtschaft.
Das ging über eine ganze Reihe von Jahren.
IBM war dort beteiligt, hat dann die IAA entwickelt,
die, nein, Naja, jedenfalls die IBM-Versicherungsarchitektur.
Da doch hier steht es auch nochmal. Also ist die Abkürzung
richtig. Ich weiß jetzt gerade nicht die Auflösung dieses Begriffs.
Jedenfalls, die sind damit auch dann als,
wollten die gerne sich als Dienstleister etablieren. Ein weiteres Beispiel,
was ich hier nennen möchte, ist für betriebliche Steuerungsproduktionssteuerungssysteme.
Die heißen Manufacturing Execution Systems. Es geht eigentlich um
die Leitung von Produktionen. Stellen Sie sich vor,
eine Fließlinie, eine Kette, vielleicht noch mehrere,
die koordiniert werden müssen mit Lager,
mit Arbeitsaufträgen,
mit bestimmten Umständen
Einstellung von Parametern um Konfirmation von Maschinen, welche Produktionsaufträge stehen an,
welche sind in welcher Reihenfolge zu machen, irgendwas muss vorgezogen werden.
Und da gibt es tatsächlich, ist das zusammengefasst worden,
die typischen Aufgaben und das war wieder hier,
bestimmte grundlegende Aufgaben, die stehen da drin in dieser MES-Richtlinie.
Da stehen irgendwie so 20 Aufgaben ungefähr, stehen drin und
die können sie direkt verwenden, um Schnittstellen zu definieren.
Und wenn sie ein System entwickeln, was diesen Standard erfolgt,
erfüllt, dann können sie davon ausgehen,
dass das vielleicht von anderen auch eingesetzt wird,
die eigentlich Produkte bei einem anderen Hersteller kaufen würden
Ein weiteres Beispiel ist Autosaar. Vielleicht haben Sie davon schon gehört,
das ist der grundlegende Standard für Kommunikation im Auto, in Fahrzeugen.
Man hat da auf dieser Basis Komponenten und Schnittstellen,
insbesondere in der Facebook, zerlegt. Die Autohersteller wollen unbedingt erreichen,
dass sie nicht von einzelnen Lieferanten abhängig sind,
sondern dass es also das ABS von verschiedenen Lieferanten geliefert werden kann.
Und da brauche ich natürlich eine einheitliche Komponentenbasierte Architektur mit einem einheitlichen Schnittstellenverhalten.
Und dieses Schnittstellenverhalten ist ein wesentlicher Kern von Autosaar. Da gehört aber noch weiteres dazu, entsprechende Analysegeräte,
die dann tatsächlich diesen Bund es auch abhören können und daran darauf arbeiten können,
Festlegungen für die verschiedenen Schnittstellen, was dort auch fachlich basiert,
was von den Zeiten her passiert, von Strömen,
Spannungen, Ausfallsicherheit spielt auch eine Rolle.
Ich möchte, weil wir bei Außerhaltssicherheit sind,
dass die Transportsysteme, wo Menschenleben gefährdet sein können,
ein besonderes Thema, zum Beispiel für Eisenbahnsignalsysteme,
also Signalsysteme sind dann die, die dafür sorgen,
dass zum Beispiel auf einer Strecke mehr als einen Zug fahren kann,
weil die Strecke einen virtuellen Abschnitt geteilt ist und wenn ein Abschnitt verlassen wird vom Zug,
wird er wieder freigegeben und das Das Ganze passiert über traglose Kommunikation.
Das heißt, der Logführer bekommt die Information, du darfst jetzt weiterfahren,
auch wenn da kein Signal steht, rot oder grün.
Diese Systeme sind sehr komplex und ich habe mir sagen lassen von Leuten,
von Kollegen, die in diesem Bereich arbeiten,
wenn sie dann im Zug hören, sie bleiben jetzt stehen wegen Signalstörung,
dann ist das eigentlich in keinem Fall,
so ist mir gesagt worden, wirklich ein Softwareproblem,
sondern in den meisten Fällen ein Bedienungsproblem,
weil diese Systeme halt sehr komplex sind.
Referenzarchitekturen sollten dabei helfen, typische Aufgaben zusammenzufassen,
typische Strukturen zu bilden,
auch hier ein Zusammenarbeit zwischen Systemen verschiedener Hersteller
zu ermöglichen
Last but not least, etwas,
was Sie auf jeden Fall schon mal gehört haben,
Java-E-I, Enterprise-Application-Systems für geschäftliche Business-Software,
da ist relativ wenig drin an vorgefertigten Entscheidungen.
Ja, wir hatten ja hier gerade eben gesagt, wo war es hier?
Ja, wir haben ähnliche Entscheidungen drin. Ja,
hier gibt es Entscheidungen über das User-Interface, über grundlegende Elemente,
über grundlegende Elemente von Ereignissen, über grundlegende Strukturen von Bausteinen,
dass man Bausteine miteinander koppeln kann.
Soweit Hier einige Beispiele für Referenzarchitekturen und damit sind wir am
Ende von Kapitel 7. Ich bringe als letztes Mal zu der Frage hin.
Hier war also die Frage zu, was ist eine Referenzarchitektur?
Unbedingt sollten sie auch noch die anderen fragen,
nämlich technische Entscheidungen, technische Modelle, technische Eigenschaften beschreiben.
Das sollten sie auch noch
der technischen Architektur zuordnen können.
Vielen Dank