Wir sind mittlerweile im Teil 2 der Vorlesung angekommen.
Das heißt, Kapitel 1 ist vorbei. Wir werden uns
jetzt mit dem Entwurf beschäftigen. Der Entwurf wird aber in
diesem Strang der Vorlesung nur eine kleine Rolle spielen,
weil Herr Kritzan am Freitag in der Freitagsvorlesung Entwurf als zentrales Thema hat.
Deswegen hier so ein bisschen Einordnung und mehr gibt es dazu nicht.
Aber wir sind jetzt hier in diesem Teil 2. Bevor ich
dazu komme, möchte ich Sie nochmal auf OML-Bücher hinweisen.
Sie hatten in den Materialien, das sind die Fullien,
die ich hier gerade zeige, die Fullien organisatorisch ist,
ganz zu Anfang, habe ich Sie darauf hingewiesen, sich mit UML-Büchern zu beschäftigen.
Ich habe hier zwei empfohlen, weitere Bücher gibt es durchaus auch.
Schreiben wir ruhig dazu. Zum Beispiel mein Kollege Bernhard Trumpe
von der RWTH Aachen. Ich muss das Ding
ein bisschen weg, damit sie das richtig sehen können.
Hat zum Beispiel auch ein UML-Buch geschrieben.
Im Prinzip ist jedes UML-Buch geeignet.
Wichtig ist UML
Ja, also das hier, das ist ganz wichtig.
Sie können sich das durchaus auch antequarisch kaufen.
UML2 ist wichtig, weil UML1 gab es einige deutliche Unterschiede.
Und ob Sie das jetzt hier zum Beispiel,
das Buch von Bernd Österreich,
da gab es Versionen mit 2,3 und 2,5, das ist letztlich egal.
Ich möchte Ihnen nochmal ans Herz legen.
Besorgen Sie sich
ein eigenes UML-Buch
Durch, also es ist hardcopy,
damit sie drin rummalen können, damit sie Ergänzungen machen können,
damit sie farbige Fähnchen dranhängen können, irgend so etwas.
Das ist wirklich ein wichtiges Arbeitsinstrument, sich mit der OML nach und nach zu beschäftigen.
Wir haben bis jetzt von dem UML einige Diakramer kennengelernt,
das lassen die ja kamen,
kannten sie vorher schon aus SE1 und SE2,
jedenfalls zum Teil, da haben wir nur die Beziehung wiederholt,
dann hatten wir das Use-Case, die ja kam,
das Aktivitätsdiagramm, das Zustandstier kam.
Ja, es werden jetzt noch weitere Diagramme folgen in diesem Abschnitt Entwurf eingeordnet,
UML ist das Standard, die Standardausdrucksform die industriell auch akzeptiert ist,
die in der Praxis angekommen ist.
Und das sollten sie beherrschen. Und das beherrschen sie nur,
indem sie damit arbeiten. Die Vorlesung bietet einige Möglichkeiten, die Übung,
auch ein paar Möglichkeiten. Statten sie mit so einem Buch,
in dem sie sich erstmal in dem Buch merken sie,
okay, da gibt es noch viel mehr,
als wir in dieser Veranstaltung behandeln.
Und nach und nach sind sie dann in der Lage,
selbst Mittelauge einzusetzen, beziehungsweise wenn sie ein UML-Diagramm haben, das zu verstehen.
Soweit. Also hier die ganz deutliche Empfehlung, kaufen sie
eins der UML-Bücher. Von diesen beiden ist das Zweite hier,
UML Klaas Klar über ein Zweitglas, klar, mein Favorit,
aber Sie sind frei damit, welches Ziel zu verwenden.
Sie dürfen natürlich auch in die Bibliothek gehen,
wenn die offen hat, sie können Online-Bücher nehmen,
aber beides hat den Nachteil, sie können nicht reinschreiben.
Sie können kein Pfännchen dran leben,
sie müssen es irgendwann, sie haben es immer nicht,
also das Online-Buch haben sie natürlich immer dabei,
aber das ist richtig als ein Arbeitswerkzeug,
sowas zu blättern, ist doch noch anders.
Also deswegen ein eigenes OML-Buch sollte ihnen ihre berufliche Karriere durchaus wert sein,
weil sie so teuer sind, die nicht.
Wir gehen jetzt zum Teil 2, das sind die Folienfest
Pakets 2 und da geht es zunächst um den Entwurf.
Ja, wir fangen an, wir haben wieder Fragen,
wie immer. Und zunächst fangen wir an damit,
was entwurft denn ist. Und bei diesem Entwurf,
wir haben ja das Beantwortungsbeschreibung schon gemacht, Ziele,
Techniken, Ergebnis, das machen wir hier auch.
Und dann möchte ich Ihnen gerne einige Entwurfsmethoden so ganz im Überblick gegenüberstellen,
zu den Sachen als Ergänzung der Sachen,
die Sie bei Herrn Kritzern jede Woche hören.
Ja, hier ist es also, wie gesagt, nur ein kleiner Bereich.
Lassen Sie uns damit starten, worum es dabei geht.
Beim Entwurf gestalte ich das System. Ich hatte schon beim letzten Abschnitt immer gesagt,
bei Anforderungsbeschreibungen gestalten Sie das System, indem Sie die Anforderungen präzise festlegen.
Sie programmieren kein einzelnes Stück, aber sie treffen die Entscheidungen.
Und wenn Sie sich an ganz zu Anfang erinnern,
die Kurve, Gewicht einer Entscheidung, das sind die Sachen,
die wir hier, wo Sie die wichtigen Entscheidungen treffen.
Beim Entwurf treffen Sie auch noch grundlegende Entscheidungen. Und diese Sachen,
die wir dabei machen, sind vor allen Dingen,
dass wir die Anforderungen,
das ist das Input für den Entwurf,
die Anforderungen nehmen und daraus
eine technische Lösung bauen
Die heißt überführen. Sie können auch Sachen bauen. Ja,
das Wort implementieren, steht für Verwirklichen,
es wird meistens für etwas programmieren genommen,
also dein Umsetzen im Quellcode beim Entwurf sind wir noch eine Stufe vorher.
Wir schaffen die Strukturen. Ja, diese Strukturen sind dann
die technische Lösung, auch Plattformentscheidungen und sowas.
Und dabei treffen wir, so haben wir dafür zu sorgen,
dass die funktionalen Sachen alle funktionieren. Funktionale Sachen sind eben
hier. Ich habe ein paar Beispiele angegeben, wirklos.
Das ist also das, was in den Use Cases passiert.
Ja, dass wir die Datenstrukturen komplett haben.
Die Beziehung zwischen den Daten, dass das grafische Benutzer,
die grafische Benutzerschnittstelle entsprechend ist
Wir müssen dafür Sorge tragen, dass die ganzen Randbedingungen,
die erfüllt sein müssen. Also wir haben einerseits Ziele,
aber die Randbedingungen, ohne die kann das System nicht laufen.
Also wenn wir es nicht schaffen,
die Gesetze zu erfüllen für Sozialabgaben oder für die richtige Berechnung der Mehrwertsteuer
oder für wie eine Bilanz auszusehen hat oder auch nur in den Industriestandard,
wie sieht ein Produkttelegramm aus, was sich an eine Werkzeugmaschine schicke,
damit die richtig ein Produkt fertigt.
Ja, das sind alles Dinge, also deswegen,
ich habe ja Beispiele von Schnittstellen angenommen.
Wenn sie das nicht schaffen, wenn sie das nicht genau
hinbekommen,
funktioniert ihr System nicht
Aber wir treffen auch, also dass diese beiden Sachen sind,
die wir bei den Anforderungen am klarsten gesagt bekommen,
Anforderungen, weil das vorangegangene Kapitel.
Aber es gibt auch noch Anforderungen,
deswegen wäre es mich hier besonders drauf hin,
die wir meistens nicht so klar bekommen, gesangt bekommen.
Und zwar sind das die nicht funktionalen Anforderungen.
Wenn ein anderes Wort dafür ist qualitative Antwort reden.
Da stört das Bildchen schon wieder in der richtigen,
an dieser Stelle, das muss man wieder wegschieben.
Ja, also die qualitative Anforderung des Ensynmym, ja,
also letztlich, manche sagen nicht funktional, manche Sachen qualitative Antwortungen.
Ich habe hier ein paar Beispiele, Gut, natürlich gibt es weitere.
Beide Qualitätseigenschaften spielen hier eine Rolle. Wir haben ja als nächsten Abschnitt Qualitätsmanagement.
Ich kenne nochmal auf diese organisatorischen Folien mit der Gliederung.
Ja, hier sehen Sie, wie im Abschnitt drei,
werden wir uns mit Qualitätsmanagement beschäftigen.
Da spielen diese Sachen hier eine große Rolle. Also,
was wir hier sehen, sind einige Qualitätseigenschaften,
die wir dann beim nächsten Mal noch genauer beschäftigt bekommen.
Das ist auch schon das, was wir dort überhaupt
erreichen wollen
Ja, ich habe hier ein Bild aus dem Buch Österreich,
das ich Ihnen gerade empfohlen habe, Michael Norman,
um zu zeigen,
wie sich Herr Österreich den Ablauf des Entwurfs vorstellt.
Kleine Testfrage an Sie? Ich sage Ihnen,
ich verrate Ihnen, das ist ein Diagramm der UML.
Ich möchte gerne von Ihnen wissen, was ist das denn für ein UML-Diagramm?
Vielleicht können wir das auch noch in der Fragerunde nach
der Vorlesung erkennen, was für ein Diagramm das ist.
Ich schreibe es mal als kleine Frage dran.
Wir machen das mal in einer anderen Farbe
Das ist ein bisschen schlecht lesbar. Die Nacht stande noch
ein Versuch. Also welches UML-Jahr kann,
um welches UML-Diagramm handelt es sich
Woran für wieder ein Fehler? Woran erkenne ich das?
Also, was sind genau die Kennzeichen dieses UML-Diagramms?
Lassen Sie uns das in der Fragestunde nach der Vorlesung diskutieren.
Sie überlegen sich in der Zwischenzeit eine Antwort. So,
also was wir hier sehen, ist ja,
dass Stärke die Überschrift schon ein Ablauf.
Der Ablauf folgt also Pfeilen und dann hier gibt es also
solche Aufgaben wie ein Schichtenmodell definieren,
ein Verteilungsmodell
Ein fachliches Subsystem, Klassenmodelle, Komponentenschnittstellen, Verantwortlichkeiten, ganz viele verschiedene Teilmodelle.
Sie erinnern sich so ein ähnliches Bild mit Teilmodellen,
hatten wir auch, also über das Anforderungsmodell gesprochen haben.
Ich möchte ein paar Begriffe hier besprechen mit Ihnen,
bevor wir ins Detail gehen.
Worum geht es denn bei Subsystemen, bei fachlichen Subsystemen?
Dabei geht es darum, welche Aufgaben hat ein System,
das Gesamtsystem? Und da gibt es Teilaufgabe,
die werden Subsystem teilen des Gesamtsystems zugeordnet
Ein Beispiel, das Maulsystem Toll Collect,
was auf dem Landstraßenautobahnen funktioniert, das besteht aus großen Systemteilen.
Und diese Systemteile sind zum Beispiel so ein Computer-System,
was neben der Straße montiert ist,
an so einer Überwachungsbrücke, die Kennzeichen erkennt, erkennt,
ob es eine endliche und ein LKW handelt und dann per Mikrowellen,
die den Austausch, Staaten, Austausch mit der Onboard-Unit eines LKWs macht.
Zusätzlich gibt es einen Datenaustausch mit dem Zentralserver,
also dieses System an der Straße
ist ein Teilsystem
Die Onboard-Unit ist auch ein Teilsystem, ein Subsystem.
Und der Zentralcomputer oder mehrere, die es da gibt,
wie im Teufelsymperiksystem, sind auch Subsysteme.
Also das waren jetzt hier so was Subsysteme. Und das
ist aufgrund von fachlichen Kriterien gegliedert. Definieren heißt immer,
so was wie Aufstellen in diesem Diakon. Verteilung, wobei jedes Verteilung,
nein, da wird nicht das Taschengeld verteilt oder Peanuts,
nein, hier wird ein System als verteiltes System gestaltet,
ein paar Aufgaben laufen auf einer Datenbank, als eingeblendete Datenbankskripte,
ein paar Sachen laufen auf den Webserver,
ein paar Sachen laufen in einem Hinterher,
dem Mobiltelefon im Client, Schichtenmodell.
Man macht häufig fachliche oder technische Schichten, Sachen,
die Hardware näher sind, die Betriebssysteme funktionieren.
Und diese Schichten werden irgendwie festgelegt. Hier, Klassenmodelle,
das können sich was drunter vorstellen, Klassendiagramme für einzelne Komponenten.
Und für diese Komponenten brauchen wir auch Schnittstellen, wie die Komponenten miteinander arbeiten.
Und natürlich auch, wenn man das entwickelt hat,
hier Tests sollte man auch irgendwie entwickeln.
Das passiert alles hier. Wenn wir denken, oh,
das macht das nicht alles, der Entwickler.
Tatsächlich gehen die Tätigkeiten ineinander über zwischen dem,
was der Architekt macht, einen Entwerfer oder dem,
was ein Entwickler macht
Ablauf, Verantwortlichkeiten. Das hat mit den Abläufen zu tun.
Wer macht denn was? Vielleicht erinnern Sie sich,
wir hatten ein Aktivitätsdiakram der UNL mit diesen Swim-Lanes, mit den Verantwortlichkeitsbereichen.
Das hat damit zu tun, indem ich sage, wer macht denn was?
Diese Information denkt sich nicht der Entwickler aus,
sondern in ganz vielen Fällen ist das relativ klar oder wird
ausgeht aus den Anforderungen hervor, nach lesende Anforderungen,
sollte ihm das klar sein.
Und wenn ich fragen Sie, in manchen Fällen entscheidet natürlich
auch der Entwickler, wer macht das am besten?
Macht das lieber der Webserver? Macht das lieber die Datenbank
? Macht das lieber das mobile Handheld oder wie auch immer
Ja. Wenn wir technisch und feindliche Zustände haben,
sollten wir dafür Modelle entwickeln. Auch Datenflüsse sollten wir versuchen,
klar auszudrücken. Und wenn es um die Interaktion geht,
dann meint es häufig die Interaktion mit den Menschen,
die Interaktionen zwischen Subsystem teilen oder zwischen Komponenten oder auch die Interaktion mit Nachbarsystemen.
So, wenn wir das Ganze, sie erinnern sich vielleicht an diesen Balken,
oben und unten, der Balken zu dieser Samenführung,
der hieß, kurz überlegen, Der hieß Synchronisation.
Ja, also das war die Synchronisation, wenn Sie sich erinnern,
die Sachen, es geht erst weiter, wenn alles erledigt ist,
die Reihenfolge ist dabei egal. Ja,
also das drückt das hier auf, hier oben ist das Gegenteil,
wo ich es aufbitte und hier die Synchronisationen,
erst wenn die ganzen Sachen fertig sind, dann entwickle ich Tests,
dann lege ich hier noch irgendwelche Attribute,
da weiß ich jetzt nicht genau,
was der Herr Österreich damit meinte.
Und ich spezifiziere Dialoge, nämlich die Nutzerschnittstelle ist damit gemeint.
Und dann ist irgendwie Schluss mit dem Entwurf,
dann würde ich es weitermachen,
dann würde ich
die Implementierung machen dafür
Also dieses, diese Schritte nehmen wir hier als Beispiel,
sie müssen die nicht auswendig lernen, um ihnen Eindruck zu geben,
was für Tätigkeiten gehören da alle dazu.
Die Frage 1, die wir hatten,
ich gehe nochmal gleich zurück zu diesen Fragen,
nennen Sie Ziele, Techniken und Ergebnis der Phase Entwurf.
Ja, und ich habe das mal hier genommen aus dem,
aus, ich habe eine Vorlesung als Softwarearchitekturen im Masterstudium,
da habe ich diese Folie mal mitgebracht,
weil Architekturentwicklung
ein Teil des Entwurfs ist
Wenn ich ihre Architektur entwickle, ist das,
entwickle ich dabei Strukturen, die man durchaus auch zum Entwurf bezeichnet,
als Entwurf bezeichnet, beim Entwurf gehört noch mehr dazu,
die Interaktion mit Nachbarsystemen,
die Gui und so etwas gehört noch mehr dazu.
Und auch der fachliche Entwurf würde man, den würde man hier mit einbeziehen,
aber ich habe diese Sache hier aus Softwarearchitektur genommen.
Die Ziele sind nämlich die gleichen. Und zwar habe ich hier vier Hauptziele,
das ist die erste, zweite, dritte,
vierte Gruppe und diese Ziele klingen überhaupt nicht technisch,
sondern diese Ziele klingen nach Projekterfolg.
Wozu brauche ich das? Effizient, was ist effizient?
Effizient ist das Verhältnis zwischen Aufwand und Nutzen
Etwas ist effizient, wenn es mit geringem Aufwand vielen Nutzen bringt.
Und effiziente Entwicklung bedeutet, dass wir mit unserer Arbeit gut vorankommen,
damit wir mit geringem Aufwand gute Ergebnisse erzielen,
effiziente Entwicklung zum Beispiel, wir wollen iterativ entwickeln.
Das ist das, sie haben alle von Scrum
gehört mit Sprints, wo ich in den Iterationen arbeite.
Und dass ich stückweise, indem ich inkrementell das mache,
das muss die Struktur erlauben, indem die Struktur,
Module vorgibt, die einzeln bearbeitet werden können,
eines,
unabhängig vom anderen
Diese Strukturen, diese Module sind auch Basis dafür,
dass hier ein Projektleiter eine Planung machen kann,
weil er einen Hund der Strukturen besser abschätzen kann,
wie viel lang braucht man dafür,
wo steckt denn die Schwierigkeiten,
was kann ich parallel bearbeiten und was kann ich nur nacheinander bearbeiten.
Und dass man das, wenn die Implementierung gemacht werden kann,
dass sich die unabhängig voneinander machen kann.
Ich kann durchaus ein Teilteam in Rumänien oder ein Teilteam in Nürnberg
daran arbeiten lassen und nicht alle Leute müssen in einem Raum
sitzen und müssen jeden Tag miteinander sprechen,
was dafür nötig ist.
Das hat also Aufwand-Nutzen-Verhältnis, das ist etwas zu den Eindruck geben,
was macht Entwurf. Wir haben noch nicht darüber gesprochen,
wie man es erreicht,
nur wohin besteht das Ziel
Weitere Ziele, mit die mit Erfolg zusammenhängen, sind Risiken auszuschließen.
Risiken, wir können sie nicht wirklich ausschließen,
aber wir können versuchen, diese Risiken zu verkleinern, zu minimieren.
Ja, das macht man zum Beispiel so mal,
indem man ein System entwickelt, wenn jemand mit den größten Risiken beginnt.
Ja, es hat keinen Zweck, irgendwas ganz nett zu machen
und ich weiß noch gar nicht, ob das Ganze funktioniert.
Zunächst sollte ich mich um die größten Risiken kümmern.
Kann das überhaupt funktionieren? Funktioniert dieses Framework auf dieser Plattform
? Kann ich da ein Protokoll hinbekommen,
was Fehler sicher über ein verteiltes System arbeitet,
ohne die Zeitverschiebung zwischen über den Nachrichtentransport, dass sich das störend auswirkt.
Solche Fragen sollte ich, wenn das kritische Fragen sind, zuerst klären.
Ja, also das hat was mit Prioritäten zu tun.
Ich sollte früh mich drum kümmern, was sind denn die kritischen Punkte,
die ich unbedingt erfüllen muss, damit so ein System einsetzbar ist.
Und ich sollte prüfen, ob ich die Anforderungen überhaupt erfüllen kann.
Das kann ich auch machen und ich sollte das machen, bevor ich implementiere.
Wenn ich ein halbes Jahr aus der Entwicklung, um dann festzustellen,
oh, ich kann gar nicht so schnell sein,
wie der Auftraggeber bin, dann ist das irgendwie ein bisschen spät.
Oder ich sollte, funktioniert denn das mit diesem Framework?
Mit diesem Tool, mit diesem Toolsystem,
mit dieser Programmsport
Das hat etwas alles mit Erfolg zu tun.
Und die rechte Seite hat auch was mit Erfolg zu tun,
aber auf andere Weise. Wir hatten gesagt,
bei größeren Systemen haben wir immer mit vielen Leuten zu tun.
Große Systeme werden nicht von zwei, drei Leuten entwickelt, sondern verschieben.
Und manchmal auch sind da spitze oder vielen Fällen Spezialisten beteiligt.
Und dann ist tatsächlich Kommunikation ein Thema, weil Leute haben
mit unterschiedlichen Bereichen unterschiedliche Sichtweisen, unterschiedliche Verständnis von Begriffen.
Und deswegen ist diese Kommunikation ganz wichtig. Es helfen uns sichten,
für jeden diesen Teil Informationen zuzuschneiden, der für ihn wichtig ist
, verständlich ist.
Und andere Sachen eben gleich auszugeben
Das brauche ich nicht nur, um die Kommunikation zwischen mir
ist das, was Stakeholder drückt, aus aller Beteiligten.
Also zwischen den Beteiligten hinzubekommen, sondern auch für neue,
wenn jemand neu ins Projekt kommt,
dann kann er aufgrund dieser Verständnis schaffenden Mittel,
zum Beispiel UML-Diakramme, schneller verstehen, worum es geht.
Und ich brauche Dokumentationen für diese verschiedenen Spezialisten aus verschiedenen Perspektiven.
Durchaus die große Perspektive durch das Wort Leidbild dargestellt,
aber auch die verallgemeinerten Sachen,
die ich für andere Projekte benutzen kann oder als Vorlage,
das wäre das,
was ich mit Referenz bezeichne
Das ist der Aspekt der Kommunikation zwischen verschiedenen Leuten,
zu verschiedenen Zeitpunkten. Aber wir haben auch noch die Zeitachse
zu beachten. Solche Systeme, die groß sind,
haben auch eine, von denen erwartet man auch,
dass sie über lange Zeit zur Verfügung stehen.
Und dazu muss ich Wissen aufheben. Es reicht nicht,
gute Entwickler zu haben, die gute Ideen haben,
nein, ich muss das Wissen auch speichern.
Ich habe hier das Wort konservieren genommen. Sie kennen alle Konserven,
die teilweise über Jahre die Qualität von,
sag mal,
physischen oder Bohnen erhalten
Oder Apfelnups. Oder was auch immer.
Und wir wollen das Wissen von über ein System erhalten.
Und dazu brauchten wir in irgendeiner Form eine Beschreibung.
Und diese Beschreibung spiegelt sich in den Entwurfsdokumenten wieder.
Ja, und es gibt verschiedene Zwecke. Ich sage mal
, ich möchte das Wissen in andere Systeme auftragen.
Natürlich zum Beispiel, um zur Weiterentwicklung des eigenen Systems.
Das steht hier gar nicht mit dabei. Ja, aber
weil das ist sozusagen grundlegend. Aber ich möchte manchmal,
dass das übertragen auf ähnliche Systeme.
Oder ich möchte Teile daraus nehmen und den woanders einsetzen.
Dann kann man auch noch sagen,
okay, da ist viel Arbeit reingeflossen,
die Arbeit ist bezahlt worden
Dass irgendwie ein Träger von Investitionen und dass damit gehört es jemand.
Sie können auch sagen, also in vielen Disziplinen gibt es Patente.
Bei Software gibt es Patente nicht möglich, nur in den USA,
aber diese Patente oder trotzdem gibt es geistiges Eigentum.
Und natürlich, wenn man das Wissen speichert,
hilft es einem auch, später das zu verbessern.
Wenn sie zum Beispiel immer ihre Testfälle speichern,
nämlich die Abläufe, die dadurch beschrieben werden,
dann können sie bei neuen Fehlern die alten Festfallbeschreibungen rausnehmen und können überlegen,
okay,
wo muss ich da was ergänzen,
dass ich den neuen Fehler auch mitfinde und damit schrittweise
etwas verbessere
Oder eine Dokumentation, die missverstanden worden war, können sie nutzen,
um sie zu verbessern, wenn sie ihn aufgehoben war.
Nur das Neue erklären hilft nicht möglich.
Also das ist die Antwort auf die Frage mit den Zielen.
Lassen Sie uns hier noch mal hinspringen.
Also das wären schon mal die Ziele hier gewesen.
Beim Entwurf gibt es Techniken, die wir einsetzen können.
Ach so, einen Punkt möchte ich hier noch ergänzen.
Ich will das mal rüber
Der hier nicht so stark drinsteht oder nur mittelbar.
Ich möchte auch vermeiden, dass ich Nacharbeit habe.
Und das kann ich dadurch machen, dass ich frühzeitig prüfe.
Das gehört ja uns zu den Risiken mit dazu.
Anforderungsermittlungen früh prüfen, das soll ich üben werden.
Deswegen, ich schreibe das mal hier
unten drunter
Ja, also das gehört sowohl zur effizienten Entwicklung,
als auch zu dem frühen Prügen Prüfung von Antwortungserfüllung.
Wir sollen relativ zeitig prüfen, ist denn das System schnell genug?
Ist das System zuverlässig genug? Ja, wenn ein System zu langsam gebaut ist,
natürlich können sie zum Schluss ein bisschen optimieren,
vielleicht fünf oder zehn Prozent, vielleicht manchmal auch 20 Prozent.
Aber wenn das System ganz stark zu langsam ist oder überhaupt nicht skaliert,
das heißt, sie erreichen ihre Grenzen vielzeitiger,
als sie es erwarten können und zum Beispiel ein Warnsystem,
Warnlieferungssystem ist für das Weihnachtsgeschäft nicht geeignet,
dann wäre das schlecht und das können wir erreichen,
indem wir diese Anforderungsermittlung frühzeitig prüfen,
um Nacharbeit zu vermeiden und Nacharbeit vermeiden,
ist dann eins der Ziele, die wir hiermit,
die hier explizit ergänzen möchte.
Ja, und damit wird natürlich eine Systementwicklung effizienter,
weil wir, wenn wir Nacharbeit sparen,
sparen wir Aufwand und damit steigern wir die Effizienz.
So, nun zu den Techniken. Beim Entwurf gibt es
eine Reihe von Vorgehensweisen, die wir machen müssen.
Natürlich können wir sagen, okay,
ich brauche einen kreativen Menschen,
den setze ich einfach dahin und der ist einfach genial und
der entwickelt in den Hof eines Systems.
Was ich also brauche,
ist genialität
Und ich gebe ein bisschen Ruhe und ein paar
süße Snacks und dann Kaffee und schon geht das.
Ist das so einfach? Im Prinzip könnte man das schon
so machen. Für viele Systeme funktioniert das tatsächlich auch.
Aber ich kann das nicht reproduzieren. Ich kann nicht sagen,
okay, das war diesmal erfolgreich. Wir werden das nächste
Projekt auch erfolgreich hinkriegen. Nein, wir brauchen Techniken.
Und diese Techniken erlauben uns, wie doch bult vorzugehen.
Und das ist das, was wir mit Entwurfsmethoden haben.
Wir haben vieler Entwurfsmethoden, ist das Bilden von Abstraktionen.
Das möchte ich
als erste Technik nennen
. . . . . . Vielleicht ein paar Beispiele.
Das sind Begriffe, Konzepte, fachliche Objekte,
typische Strukturen.
Diese fachlichen Objekte das sind
Dabei eben, solche Abstraktionen, das sind fachliche Abstraktionen.
Das sind Ende hinter typischen Strukturen, ja, oder das sind technische Abstraktionen.
Die fachlichen Abstraktionen sind zum Beispiel diese Begriffe hier und die
fachlichen Objekte und dann haben wir eben noch die technischen Abstraktionen
Und das wären zum Beispiel die typischen Schnittstelle, die typischen Strukturen,
aber wir können auch sowas haben wie typische Schnittstellen.
Ich habe eine Pfeile dran, ich muss ja wissen,
was damit gemeint ist
Diese verallgemeinerten Schnittstellen helfen, ist dann Systeme in einer bestimmten Weise aufzubauen.
Das trägt dazu bei, dass Leute sich besser zurechtfinden,
wenn sie besser zu sich zurechtfinden, finden sie schneller zurecht,
machen weniger Fehler und diese weniger Fehler sind eben das,
was hier zu effizienter Entwicklung beiträgt.
Das ist das eine. Und dann ist es auch insofern besser strukturiert,
die fachliche Struktur ist leichter erkennbar. Es passt besser zu dem,
wie wir das fachlich strukturiert haben und dann ist Arbeitsteilung besser.
Macht möglich. Zum Beispiel, es gibt einen Teil,
der sich um Steuerbearbeitung hin und Und alle Änderungen,
die da drin sind, die Regeln von Steuern letztlich abbilden,
das macht jemand, der sich mit Steuern sehr gut auskennt.
Während einen anderen Teil, der wo es um organisatorische Abläufe, sagen wir mal,
in der Papierproduktion geht, da kümmert sich der Papierverfahrenstechniker darum.
Und wenn wir das schön voneinander trennen,
ist das eine, macht das eine das andere,
das andere, nämlich diese fachliche Struktur, die fachlichen Abstraktionen,
dann ist das System besser gegliedert.
Das ist also die erste Technik Abstraktionenbild
Es gibt ganz wesentliche Abstraktionen, auch in den Methoden,
die sie bei Herrn Gritzer anhören.
Ja, also das ist doch fachliche Strukturen,
bilden zum Beispiel erkenne, indem ich einen Bounded-Kontext erkennen möchte.
Das ist auch eine fachliche Struktur. Aber ich möchte im
Michio stark über seine Begriffe reden, sondern hier mehr über
die bei uns und deswegen zu einer weiteren Technik kommen.
Und die nennen Modelle entwickeln. Was ist ein Modell?
Im Modell ist eine vereinfachte Darstellung der Realität,
vereinfacht im Sinne von,
ich lasse die Tails weg,
ich kann
den Überblick besser erfassen
Was mache ich mit so einem Modell?
Ich lasse Unwichtiges weg. Etwas, was nicht relevant ist,
nicht, weil mantes Weglassen, das wäre ein Punkt.
Und natürlich das Umgekehrte, genau die relevante Information darstellen
So, dass ich für den Bearbeiter das herausstelle, was er denn braucht.
Und verschiedene Bearbeiter, unterschiedliche Sachen in Betracht ziehen.
Also derjenige, der zum Beispiel ein System installiert,
der interessiert sich nicht genau, wie die Staffel Struktur ist.
Der interessiert sich, was muss denn auf welchem Gerät,
auf welchem Subsystem laufen? Wo brauche ich Lockwärts,
die ich überwachen muss, als etwas richtig funktioniert?
Wo muss ich Parameter einstellen, die zueinander passen müssen?
Der braucht andere Sachen als jemand,
der sich um Security kümmert oder um Datenschutz oder um
die Benutzerschuhe
Dass wir verschiedene Sachen darstellen, verschiedene Sachen,
wie relevant sind, das Erlaubten in Sichte.
Solche Sichten sind zum Beispiel die Sicht auf die Struktur.
Eine Teile, wie hängen sie zusammen?
Oder die Sicht auf das Verhalten? Ich könne noch
eine Sicht haben für ein verteiltes System.
Wie ist es,
Verteidiger,
verschiedene Rechnerknoten
Ähm, oder auf Zuordnung von Arbeitspaketen zueinander. Das wäre die Basis dafür,
dass ein Projektleiter sagt, du machst das Arbeitspaket,
du machst das Arbeitspaket, du machst das Arbeitspaket.
Und diese verschiedenen Sichten hängen damit zusammen,
das ist relevant, was ich hier habe,
das hängt damit zusammen,
für welchen Zweck
Der Zweck ist entscheidend, soll das heißen,
das passt aber nicht ganz hin. Naja, versuch.
Ich weiß nicht, möglich. Zweck ist entscheidend,
ja, und dieser Zweck, der entscheidend ist,
das hat an dem, was ist denn relevant,
ja,
und was ist die richtige Sicht
Das ist das, was den Zweck bestimmt. Und natürlich,
das hatten wir eben bei den Zielen schon,
das ist auch eine weitere Technik, frühteilige Prüfung.
Ich habe die Ziele eines Projektes beziehungsweise erreicht beziehungsweise die Anforderungen
erfüllt werden
Damit sehen wir die, wenn wir da falsche Entscheidungen treffen,
zum Beispiel falsche Entscheidungen über Werkzeuge, die wir einsetzen,
falsche Entscheidungen über grundlegende Strukturen, Design-Patterns, über Architekturmuster,
dann wären wir, das könnten wir nicht mehr reparieren, nur durch Implementierung.
Soweit zu den Techniken und die Frage,
wir schauen nochmal hier in diese, zu den Fragen,
ja, das wäre also hier zu den Zielen,
hätten wir schon eben auf der Folie alles gesagt,
zu den Technik,
Ebo nun natürlich noch zum Ergebnis,
was für Ergebnisse sind denn
hier zu erwarten
Zum einen sind Ergebnisse Modelle, nämlich Entwurfsmodelle.
Die sind der Input oder die Vorgabe für die Implementierung.
Und als Mittel der Kommunikation.
Und der Konservierung von Wissen
Das waren diese beiden Punkte, die wir bei den Zielen schon mit dabei haben.
Das ist ein Ergebnis, dass wir solche Modelle erstellen,
mit ein weiteres Ergebnis, was ich hier einführen möchte.
Es ist natürlich sehr global, sehr abstrakt. Es gibt
eine ganze Menge Modelle. Und wenn wir nochmal hier,
ich schaue einfach mal nochmal zurück zu diesem Bild von Österreich.
Der hat hier ganz viele verschiedene Sachen gemacht.
Hier waren Zustandsmodelle, Objektflussmodelle, Interaktionsmodelle, Ablaufmodelle oder Verantwortlichkeiten.
Diese Komponentenmodelle, Verteilungsmodellen, all das Manny meine ich damit.
Das ist das Ergebnis, diese ganzen,
diese Modelle und ob die jetzt genauso heißen wie auf dieser Folie
oder am ein bisschen anderes hängt, ein bisschen dafür ab.
Worum liegt der Fokus eines Projektes? Wenn ein Projekt keine
verteilte Anwendung haben hat, dann brauche ich natürlich den verteilten Sachen nicht.
Und wenn das nicht so viele Zustände hat, dann kann ich
mir das Zustandsmodell sparen. Ich kriege am Ende keinen Preis dafür,
wenn ich besonders schöne Modelle habe,
sondern ich kriege nur einen Preis dafür,
wenn ich erfolgreich mein System entwickelt habe,
im Sinne von erfolgreich von aller Anforderungen werden erfüllt.
Machen lassen wir uns weitermachen mit den Ergebnissen.
Ein weiterer Punkt, den ich hier nennen müsste,
sind Entscheidungen
Ich habe am Ende des Entwurfs Entscheidungen getroffen, und zwar Entscheidungen über technische Lösungen.
Dieses Treffen von Entscheidungen, es klingt irgendwie sehr trivial,
ja, also viele Sachen, von denen sie,
die sie von mir jetzt hier heute hören,
klingt doch irgendwie trivial.
Na klar schreibe ich das in irgendeiner Form auf,
was ich mache. Klar treffe ich irgendwie Entscheidungen.
Das Problem ist, das zu ist nicht so klar.
Ja, wir haben viele Zeitgenossen, viele Kollegen,
die Entscheidungen treffen, aber sich der Sachen gar nicht bewusst sind.
Und wenn sie die fragen, warum machst du denn
da so
Das habe ich schon immer so gemacht, ja?
Oder die haben das woanders mal so gesehen. Und die
hinterfragen das aber auch nicht, ob das passend ist.
Und dann gehen sie haarscharf an der optimalen Lösung vorbei oder
manchmal meilenweit an der Lösung vorbei.
Es funktioniert gar nicht. Oder es gäbe eine bessere Lösung
. Ja, also diese Entscheidungen für technische Lösungen treffen,
abwägen, was ist denn das Richtige?
Das ist ein wichtiger Punkt, solcher in dieser Phase Entwurf.
Ich möchte zwei Beispiele bringen für Entscheidungen oder für Typen von Entscheidungen
. Das eine wäre Entscheidung über Werkzeuge. Oder Entscheidungen über
die technische Plattform
Plattformen meine ich, so als wie sie ein Framework oder eine Technologie.
Zum Beispiel, ich mache das alles mit Microsoft.net.
Es wäre auch mit den Original-Technologien möglich oder mit den Technologien,
die IPM so verkauft,
aber ich entscheide mich für Microsoft dort nicht,
weil das dann da gut passt oder weil meine Entwicklung schon
viel Erfahrung haben oder weil der Kunde noch mehr davon einsetzt.
Oder weil die Lizenzen billig sind. Es gibt verschiedene Gründe,
sich für eine bestimmte Plattform zu entscheiden oder weil der Support besonders gut ist.
Und wenn einer sagt, ich nehme Open Source,
weil ich da alle Rechte davon habe,
ja dummerweise gibt es keinen Support.
Bei Microsoft kriegt ja vielleicht mehr Support.
Also das sind Gründe für eine Entscheidung,
die nicht nur technischer Natur sind
Also, ich entscheide mich für Werkzeuge als Beispiel.
Ich entscheide mich für die Plattform oder ich entscheide mich für
bestimmte Komponenten, die ich einfach so bekommen kann.
Wie also am Markt verfügbar sind, die ich kaufen kann.
Ich muss sie nicht selbst entwickeln. Ich muss nicht selbst
alles entwickeln für ein über Verschlüsselungs-Famework zur Übertragung mit dem verteidigen System.
Oder für den Poker in einem serviceorientierten System,
mich mit Registry und im Trickwest bekommt.
Brauche ich nicht. Ich kann es direkt so benutzen,
wenn ich mir etwas ein Produkt kaufe,
was meine Anforderungen erfüllt,
aber welches,
das ist eine Entscheidung
Ja. So, das sind Teile,
die am Ende mit mirheim zu meinem System gehören werden,
die das leisten sollen,
was ich leisten muss und Teileaufgaben für mir Arbeit abnehmen.
Und ich kaufe mir die für Geld oder Lizenzgebühren, was abgeht ist.
Und ein weiterer Punkt, wo ich Entscheidungen treffen muss,
ist Entscheidung, wie gehe ich denn vor?
Ich entscheide mich über Vorgehensweisen. Funkinsweisen sind solche Sachen,
wie sie eben zum Beispiel bei Domaintriven Design hören,
wie entwickle ich das, wie gehe ich vor, was analysiere ich?
Sie haben in SE1 SE2 vielleicht was von Werkzeugmaterialeinsatz gehört,
wann, ja, da entwickle ich klingelrich das System,
was ist ein Werkzeug,
was ist ein Material
Das ist ein Fachwerk natürlich auch noch.
Aber das mache ich in einer bestimmten Reihenfolge.
Und wie gehe ich bei dieser Reihenfolge vor?
Das ist von Erfahrung geprägt. Solche Vorgehensweisen brauche ich nicht
nur beim Entwickeln. Beim Entwurf, bei Implementierung. Ja,
auf jeden Fall auch, wenn ich die Teile zusammenbaue.
Das nennen wir Integration. Und ich möchte ausprobieren hier
in Betriebnahme nennen
In Betriebnahme ist nicht immer so einfach,
wie ich installiere eine Software, klicke auf das Stellpaket,
installieren, vielleicht noch ein Passwort eingeben und fertig.
Nein, wenn Sie in einer Bank ein neues System bestellen,
müssen Sie zum Beispiel die alten Daten importieren.
Und wenn die Datenformate sich geändert haben, müssen Sie
die Daten konvertieren. Dabei durfte kein Fehler passieren,
weil Sie alle würden sich nicht folgen,
wenn wir mit sich auf Ihrem Konto Müll draufsteht,
weil irgendwie die Privatierung des alten Kundestands ist fehlgeschlagen bei der Update übers Wochenende.
Ja, also auch diese,
da gehören eine ganze Menge Aufgaben dazu,
die auch, ich sage mal,
Krebs erfordern im Sinne von Erfahrungen und Kenntnis
Ja, ich muss die richtigen Vorgehensweisen dazu wählen.
Das sind zwei Beispiele, die ich hier zwei große Gruppe
von Ergebnissen, die ich nennen möchte.
Und die Entscheidungen über Vorgehensweisen, da können wir hier gleich anhüpfen,
das machen wir beim nächsten Mal.
Oder beim nächsten Folie geht das weiter. Das ist,
das sind zum Beispiel in Wurfsmethoden. In der Anfangsphase eines
Projektes entscheide ich danach, was für Entwurfsmethoden Entwurfsvorgehensweisen wende ich
denn an
Was wir jetzt hier hatten, war die Antwort auf die Frage eins.
Zieletechnikergebnissen der Phaseentwurf. Weiter geht es. Mit Beispielen für Entwurfsmethoden
. Diese Folie nennt nur Entwurfsmethoden, die sie zweifeln,
mit denen sie Kontakt haben. Und weitere, vor die ich entspricht,
erstmal nur ein paar Namen nennen möchte. Ich fange mal mit dem an,
was sie jetzt im Moment bei Herrn Gritzern im zweiten Teil der Softwaretechnikvorlesung hören,
nämlich das ist Domain treffen Design und dem Werkzeugmaterialansatz in Teilen,
der sich da niedergeschlagen hat, in den Sachen, die Herr Gritzan hier bespricht.
Ja, man kann, die wissen vielleicht,
dass Nazynikhofen ein Professor in diesem Fachbereich war,
bis vor, ich denke,
sieben Jahren und dann sich so langsam zurückgezogen hatte und sich dann nur noch um seine Firma gekümmert hat und nach der Fritzheim war ein Mitarbeiter von Herrn Zürichhofen,
hat vieles auch von Lehraufgaben hier gemacht und dieser Werkzeugmaterialeinsatz ist eine Entwurfsmethode,
die der Herr Zönighofen mit Kollegen zusammen entwickelt hat,
die hier jahrelang im Fachbereich gelehrt wurden, die teilweise,
SE2,
noch eine kleine Rolle spielt.
Und der Domänentreffen Designansatz von Eric Evans ist der Autor.
Also hier steht immer der Autor dahinter oder einer der Hauptautoren,
der hat Zönighofen, ja Evans.
Das ist unabhängig natürlich, muss man so sagen,
unabhängig entwickelt worden von den Arbeiten von den Zönighofen,
aber es knüpft inhaltlich mit sehr vielen Ideen an.
Es ist einfach weiterentwickelt worden bis heute. Ja,
und deswegen ist das ein Ansatz,
den wir
auch für wichtig halten
Zusätzlich möchte ich hier noch, habe ich hier noch ältere Sachen mitgenannt.
Zum Beispiel habe ich hier OOSE genannt. Sie können vielleicht raten,
was diese Abkürzung, objektorientiertes Systementwicklung oder Softwareentwicklung heißt.
Und dieser Name Jacobson, das ist einer der Finder der UML.
Sie haben hier in dieser Veranstaltung ein bisschen mit UML zu tun.
Der Unified Moderling Language und die Unified Moschel in dem Language
ist im Wesentlichen von drei wichtigen einflussreichen Leuten der Objekte orientierten Technologien entwickelt wurden.
Das war Iva Jacobson, war einer von den dreien,
Butch und Rambo gehören auch noch mit dazu
Zwei Leute haben die UML zusammen entwickelt und jeder hat da
etwas beigetragen und immer Jacobson hat zum Beispiel eine Entwurfsmethodik beigetragen.
Bootsch hat auch was mit Entwurfsmethodik gemacht,
wie ich klassen und Objekte finde, um noch viel mehr.
Und hier dieses Jacobson, da werden wir gerade gleich einen kleinen,
eine Idee daraus mal besprechen, was ist denn gemeint mit dem,
was wir hier eben hatten bei Vorgehensweisen, Entwurfsmethoden.
Ja, ich möchte ihn dabei jeweils eine Idee davon nennen.
Noch vorher, das sehen Sie in der Jahreszahl,
wurde Objektorientierung hat man versucht, große Systeme dadurch zu beherrschen,
dass man überhaupt erstmalig strukturierte ansätze, einführte,
indem man versuchte, Strukturen zu entwickeln, Strukturen zu entdecken.
Das ist das, was wir hier heute sagen.
Wir treffen, wir bilden Abstraktionen. Ja,
also diese Abstraktionen bilden, das ist der Kern dessen,
was man den strukturierten Methoden macht.
Diese strukturierten Methoden sind also eine der ersten,
die ich hier, ich möchte die einfach nur nennen,
so jeder nenne ich ein kleines bisschen und da gehen wir auch schon weiter.
Ich möchte nur noch sagen,
was gehört hier alles dazu,
zu so einer Entwurfsmethode
Zu diesen Entwurfsmethoden, ich schreibe es mal hier oben hin,
zu diesen Entwurfsmethoden gehören grundsätzlich Vorgehensweise im Großen.
Sebastian, die Schritte? Wie mache ich das? Ja,
damals hat man das eher so in großen Blöcken und Folgen von Aktivitäten gedacht heute,
denkt man eher an, wie organisiere ich das,
wie sieht das mit Scrum kennen, iterativ,
zum Beispiel in Sprints, ja,
also Vorgehensweisen spielt mir eine Rolle.
Dann hat man, was für Abstraktionen spielen eine Rolle
Und wie finde ich die bis hin zu lehrbuchartigen Übungen?
Empfehlungen für Abstraktionen gehört dazu, jeder dieser Techniken dazu.
Dann, wie beschreibt man das Ganze auf?
Was für Modelle stellt man dabei auf?
Und all diese Sachen stellen es die Entwurfsmethoden und diese ganzen
Sachen würde ich mal mit dem Begriff Best Practice bezeichnen
West Practice ist ein Ausdruck dafür,
der es im amerikanischen Leben und Denken kommt,
ist ein Ansatz, ist die Idee dafür,
dass ich sage, das ist das gesammelte Wissen,
wenn man, wenn du es so machst,
kannst du es nur richtig machen.
Die Amerikaner haben Verwind mit diesem Begriff, die Vorstellung,
es gibt den Idealweg zur Lösung.
Und diesen Idealweg musst du nur beschreiten. Du musst nur
den Regeln folgen. Man versucht, diesen Idealweg zu beschreiben,
wirf es klar und dann versucht man ihn zu lehren und die Leute,
die denen machen, die werden dann auch kontrolliert,
ob sie ja diesen Weg befolgen.
In unserem Leben gibt es das in ganz vielen Bereichen,
insbesondere dann, wenn Mitarbeiter bestimmte Prozenturen erfolgen müssen.
Zum Beispiel, wie wird eine Steuerprüfung gemacht?
Wie wird, wie erfolgt die Prüfung eines Bauwerks auf Tragfähigkeit?
Da muss man bestimmte Schritte erfolgen. Oder wie wird ein Medikament
geprüft oder entwickelt bis zur Freigabe für die Anwendung am Menschen
All diese Vorgehensweisen folgen einer bestimmten Regelwerk. Ja,
und das bezeichnet man durchaus als Best Pike des Aachen,
vielleicht noch ein Beispiel, vielleicht weiß der eine oder andere von ihm,
dass es für die Behandlung der medizinische Behandlung Leitlinien gibt.
Ja, der Arzt hatte bestimmte Leitlinien, wie behandelt er Lungenentzündung. Ja,
da gibt es bestimmte, nur aus dem Fall,
in dem Fall, in dem Fall vorher prüfen,
ist das überhaupt oder kann es vielleicht was anderes sein,
kann es vielleicht eine Lungenenvolice sein oder was anderes,
gibt es andere Ursachen,
hat derjenige vielleicht bloß was verschluckt oder keine Ahnung,
was es noch alles sein kann,
es ist nur eine Reizung,
ich bin da kein Mediziner und dann folge
den und den und den Schritten
Der Arzt darf vielleicht davon abweichen, aber er muss diese Abweichung bekunden.
Er muss sagen, ja, im Prinzip, ja,
ich kenne diese Sachen. Und das ist hier auch so,
wir wollen erreichen, dass wir mit diesen Entwurfsmethoden,
das ist nicht so etwas,
was wir sklavisch verfolgen oder dass man gar auf Knopfdruck ausführen kann,
weil es automatisierbar ist.
Nein, das ist sowas wie so eine Leitlinie,
wie gehe ich denn vor? Und das wollen wir
uns am Beispiel gerade mal anschauen und nicht mehr sage,
so in einzelnen Beispielen kurz was, worum es dabei geht.
Bei diesen strukturierter Analyse und Design hätte ich schon gesagt,
es geht um Abstraktionen
Es geht im Kern darum, funktionale Strukturen zu erkennen.
Datenflüsse zu erkennen und diese Fladenflüsse zu visualisieren, darzustellen,
zu strukturieren, zu sagen, wie hängen denn die Dinge zusammen,
um dann zu sagen, ja okay,
für diese Funktion brauche ich die und die Parameter.
Und damit habe ich die Möglichkeit,
eine Schnittstelle für einen Baustein, für ein Modul zu definieren.
Der Begriff Modul kam erst in den 80ern. Aber das sind
die Entscheidungen, die ich dann treffe, damit Arbeitsteilung gelingt.
Arbeitsteilung gelingt nur, wenn klar ist, der macht bis dahin,
und das ist die Übergabe und das andere, das macht der Nächste.
Sie kennen das von den Fragen, die wir mit
dem Vertragsmodell zum Beispiel haben, Klienten und Aufrufer.
Das sind die Teelen und Dienstleister. Das waren zum Beispiel Sachen,
wie definiere ich die Schnittstelle, dieser Vertrag, den kannten Sie,
so kann ich mir auch die Arbeitsteilung zwischen Entwicklern vorstellen.
Du machst das. Und wenn du das lieferst,
kann ich damit das machen.
Und das kann man vielleicht vorher schon festlegen.
Das ist Entwurf
Also dann hatte ich kurz schon erwähnt, zur OSE,
da geht es um Objektorientierung, da spielen zum Beispiel eine Rolle,
dass ich Objekte, wie kann ich Objekte finden?
Und zwar ausgehend von fachlichen Objekten, Objekten der Realen Welt,
wie kann ich solche Objekte gut gliedern,
dass sie zum Beispiel lose Kopplung haben,
dass sie Module haben,
dass ich mir das Idee alle Welt damit abbilde.
Das war ja eine der wesentlichen Ideen von Objektorientieren
Dann habe ich hier noch etwas genannt,
für dem Sie ziemlich sicher noch nichts gehört haben.
Das ist etwas, was in einem deutschen Beratungsunternehmen SD&M,
hießen die Software-Design in Management, entwickelt worden ist.
Quasar steht für Qualitätssoftware-Architektur. Also das ist sozusagen das Akkronym von dem hier,
was so aus Qualitätssoftware-Architektur, das ist das gesammelte Wissen.
Das war eine Beratungsfirma. Mittlerweile ist sie von Capgemini
übernommen worden vor, ich denke, bestimmt 15 Jahren.
Und der Sie das Leben war dort Entwicklungsleiter einer der technologischen Vordenker.
Ich glaube, er ist jetzt Professor in der Fachhochschule in Rosenheim
und er hat unter anderem ein Buch hier geschrieben für Softwareentwicklung
Und in diesem Buch haben sie Methoden hier zusammengestellt und wir verwenden hier nur ein,
ich möchte Ihnen nur einen Punkt dann gleich mal nennen,
nämlich zur fachlichen und technischen Gliederung in Sichte.
Fachliche und technische Gliederung von Systemen. Eine Idee werde ich
Ihnen dazu überaus präsentieren. Diese beiden sind die,
die in die Freitagsvorlesung von den Gritzern stark einfließen.
Da geht es darum,
wie entwickle ich Strukturen
Dazu sage ich nichts weiter, weil sie dazu Bayern sozusagen
sehr viel hören, Strukturen entwickeln und am Ende gestalte ich Systeme.
Ich nenne mir Systeme mal Anwendungen. Ja, durch das Systeme. So,
und dann als letztes habe ich noch etwas relativ Neues,
was bis heute eine der Schlager noch sind, serviceorientierte Architekturen.
Die Idee dabei ist, dass ich in einem verteilten System
unabhängige Services habe und damit mehr Skalierbarkeit erreiche,
bis zu ihnen, zu Microservice-Architekturen.
Und hier Unabhängige Dienste oder Dienstleistungen zu Entwicklern mit dem Ziel,
Verteilung und Skalierbarkeit zu erreichen. Soweit ein Überblick,
über diese Sache möchte ich kurz sprechen,
das mache ich aber erstmal hier einen kurzen Break und das
passiert in der nächsten Einheit