Ein bisschen was von meinem Lieblingsthema zeigen, Architekturanalyse,
so ein bisschen habt ihr das ja immer schon mal abbekommen in den letzten Wochen.
Heute habe ich euch das Tool mitgebracht,
mit dem man sich das ansehen kann.
Und dann werden wir uns noch ein bisschen mit der Frage,
wie kann man eigentlich in Software was messen?
An der werden wir uns noch so ein bisschen erfreuen.
Ja, so machen wir es noch.
Ich habe alles noch gar nicht eingestellt hier, richtig.
Mal gucken.
So, gut
Was werden wir heute machen? Das ist einer meiner Lieblingssätze.
Ich rede ja mit euch auch immer über das Testen.
Also einerseits habt ihr ja ein bisschen was über Anforderungsermittlungen bei Guido gelernt,
also darüber, wie man sich Feedback von Menschen holt in Feedbackschleifen,
in Autokritikerzyklen oder sowas.
Und auf der anderen Seite reden wir ja immer sehr gerne und
sehr viel über Testen. Und ich will heute mit euch
auf die Themen konstruktive und analytische Qualitätssicherung gucken,
die stehen da jetzt beide,
weil manche sich einfach nochmal klar machen kann,
dass man die so ein bisschen gegenüberstellen kann
Ein WLAN ist hier, das ist aber hübsch.
Dann werde ich euch was zur Architekturanalyse zeigen,
was man so in Softwaretechnik messen kann und euch ein paar Beispiele für Produktvermessungen zeigen.
So, und nur so als Klassifizierung, man unterscheidet,
oh, eine Frage.
Oh, klar, habe ich vergessen heute, ne?
Verdunkelung. Welche Seite muss ich denn verdunkeln?
Die. Ist das Westen? Oder Osten? Ich versuche
jetzt mal Osten
Funktioniert. Wollen wir gleich mal gucken. Ob
das reicht oder ob wir auch noch Westen verdunkeln müssen.
Aus, das Licht kann ich das?
Jetzt gut
Alle zufrieden, da auch noch verdunkeln. Nein, gut
. Hier gibt es alles. Feedback wird sofort umgesetzt.
Konstruktive Qualitätssicherung, genau. Also, die findet normalerweise im Prozess statt.
Also, wenn man Software entwickelt, dass man vorher sagt,
okay, was haben wir hier für Qualitätsstandards?
Wer ist dafür zuständig, die zu überprüfen? Also zum Beispiel sowas wie,
die Software kommt nur in Produktion,
wenn keine schweren Fehler mehr da sind und die als Mittel
von den mittleren Fehlern gibt es noch 50 oder irgend sowas.
Ja, also sowas könnte man ja machen. Und dass man
irgendwelche Zwischenergebnisse hat, die man auch immer wieder überprüft.
Ich weiß nicht, ob Guido zu euch von dem Autokritikerzyklus gesprochen hat.
Aber das ist ja auch nicht schwer zu verstehen.
Es gibt also einen, der ein Dokument schreibt und einen anderen,
der ihn kritisiert und sowas wird zyklisch immer weiter fortgesetzt,
bis man zu einem Dokument kommt, was man gemeinsam versteht.
Sowas ähnliches sind ja auch Reviews im Endeffekt. Das ist
auch eine Form von Autokritikerzyklus. Also das alles sind Maßnahmen,
um konstruktiv Qualität zu sichern, agile Softwareentwicklung gehört auch auf jeden Fall dazu.
Aber es gibt auch noch den Begriff analytische Qualitätssicherung und
da guckt man eigentlich eher das fertige Produkt an.
Also man versucht systematisch bevor man das System in Produktion bringt,
es zu testen. Andere Leute machen Verifikationen. Darüber werde ich
euch nichts erzählen, weil ich verstehe davon auch nicht wirklich viel.
Aber sowas braucht man eigentlich hauptsächlich,
wenn man zum Beispiel Flugzeuge baut oder Raketen,
weil die so sicher sein müssen, dass die nicht abstürzen.
Die Software in einer Bank, die darf dann doch
noch mal hin und wieder abstürzen. So,
und wir werden uns jetzt eher so der analytischen Seite eben
auch widmen und uns speziell mit der Frage der Produktqualität beschäftigen.
Wir hatten ja auch immer mal diese Qualitätsdarstellung,
also es geht nicht um Prozessqualität, was wir jetzt machen.
Es geht auch nicht um Gebrauchsqualität, also dass der Anwender
das benutzen kann, sondern es geht um Produktqualität.
Also was für Qualitätsmerkmale kann ich an dem Softwareprodukt,
an seiner Architektur, an seinem Source-Code festmachen,
um zu bewerten, ob das in irgendeinem guten Zustand ist.
So. Und was ich mit euch jetzt als erstes machen will,
ist etwas, das nennt sich Architekturanalyse.
Was macht man da? Da untersucht man die innere Struktur von
einem Software-Produkt, um die Architektur zu verstehen erstmal. Ja,
also wenn man die Software nicht selber entwickelt hat,
dann versteht man häufig ja gar nicht,
wie die aufgebaut ist, sie zu bewerten, ja,
das ist der analytische Aspekt daran.
Also ich will bewerten, wie die Software eigentlich gebaut ist,
was ist ihre Qualität und natürlich um potenzielle Gefahren aufzudecken und dann auch zu sagen,
wie soll man jetzt eigentlich hier weiterarbeiten?
So, und ein wichtiges Konzept muss man verstehen,
um sich damit auseinanderzusetzen. Man muss sich im Klaren darüber sein,
dass es eine Sollarchitektur und eine Ist-Architektur gibt, wenn man Architekturanalyse macht.
Es ist nicht schwer zu verstehen. Es gibt nämlich einen Plan,
wie die Software gebaut sein soll und es gibt die Realität,
wie das Ding wirklich gebaut ist.
Ja, das gibt es in allen Disziplinen,
auch beim Haus und so weiter
So, und in der Sollarchitektur haben wir meistens irgend so
ein hübsches Diagramm. Sowas malen wir ja auch,
oder malt ihr vielleicht auch, wenn ihr Softwaresysteme baut.
Wir haben das ja auch selber hier an der Tafel gemacht.
Ihr erinnert euch vielleicht an die Paketdiagramme, die wir mal gemalt haben.
Ja, das könnt ihr hier auch ein Paketdiagramm sein.
Das ist jetzt nur eine vereinfachte Form,
was man also hier sieht, ist,
es gibt irgendwelche Elemente hier, so diese grauen Kästen,
ja, und die sind wiederum in irgendwelchen übergeordneten Elementen drin und haben Beziehungen zueinander.
Sowas würde man normalerweise bei einer Sollarchitektur auch aufmalen.
Die Leuten würden zum Beispiel Schichten malen, ja,
also man könnte ja auch sagen, ey,
das sind zwei Schichten, die untere Schicht und die obere Schicht,
ja,
oder Leute sagen,
ich male Komponenten auf
Oder ich, man sieht hier die Subsysteme und wenn die Leute auf Paketebene
das malen, dann sieht man hier Pakete und Klassen.
So, das ist also der Plan oder das, was die Leute im Kopf haben.
Und auf der anderen Seite hat man den Quelltext, ja. Also das,
was die Leute tatsächlich programmiert haben und es ist natürlich immer so,
dass die Leute gedacht haben,
ich mache mal die Architektur so und so,
die haben sich also einen Plan vorher gemacht und dann haben sie was gebaut.
Und wenn sie dann das bauen,
dann stellen sie fest, der Plan war zwar toll,
aber ich kann ihn so nicht umsetzen.
Ich muss was anderes machen, als ich geplant hatte.
Also wird es einen Unterschied geben zwischen der Säule und
der Istarchitektur
Und wenn ich also, ich zeige euch gleich das Tool,
mit dem man sowas gut machen kann,
aber wenn ich in Firmen gehe und mir dort die Architektur angucke,
dann ist eine meiner ersten Dinge,
auf die ich achte, ist die Frage,
finde ich das, was die Leute mal geplant haben,
eigentlich überhaupt in der Struktur, die sie nachher implementiert haben,
wieder?
Ist das die geplante Architektur in der Implementation wiederzufinden?
Ich werde euch das gleich
auch nochmal zeigen
Das zeige ich euch nur, um auch mal zur Erinnerung,
ne, das werden wir gleich, wenn wir auf das Toolpunkt,
ich glaube, die Folie habe ich jetzt schon dreimal gezeigt oder so,
ihr solltet sie inzwischen kennen und auch merken,
wie wichtig das ist, dass man das offensichtlich kann, ja.
Wir haben in unseren objektorientierten Architekturen Klassen und die haben Beziehungen zueinander,
die Klassen und dann gibt es da eine übergeordnete Struktur,
da habe ich jetzt mal Subsystem reingeschrieben,
in Java sind das natürlich die Packages und da sind die drin enthalten,
ja, und diese übergeordneten Strukturen sind wiederum in übergeordneten Strukturen enthalten,
ja, Subsysteme sind in Subsystemen, sind in Subsystemen,
sind in Subsystemen und so weiter.
Ja, das ist der ganze Zauber und man hat eigentlich
nur auf der Klassenebene irgendwelche Beziehungen, ja, Benutzung und Vererbung.
Aber wenn man das System zusammenfaltet, also die unteren Ebenen weglässt,
dann stellt man die Beziehungen auf den übergeordneten Ebenen dar.
Das werdet ihr gleich auch sehen. Da wird das aggregiert. So,
das habe ich jetzt das dritte Mal erzählt und ich glaube,
wenn man das das dritte Mal hört,
dann behält man das auch, glaube ich.
Ich glaube, ich zeige die Folie jetzt nicht nochmal.
Aber ich will nichts versprechen, wer weiß.
Vielleicht ist sie irgendwann nochmal wichtig.
Und was ich euch also jetzt zeigen will, ist ein Tool,
was ich viel benutze, um solche Architekturanalysen zu machen.
Das heißt, Sodo-Arc und Sodograf, das hat zwei Namen,
weil der eine Teil ist eher so auf Tabellen ausgerichtet,
das ist der Sodograf und der Sodo-Arc macht eher so hübsche,
bunte Bilder.
Das ist ein System, was seit 2002 kommerziell auf dem
Markt ist und ich kenne einfach die Leute gut,
die das gebaut haben und habe mich von Anfang an mit dem Tool beschäftigt.
Deswegen kenne ich mich da gut mit aus.
Es gibt auch noch andere Tools auf dem Markt,
die man durchaus verwenden kann,
aber es ging mir hauptsächlich darum,
dass ihr
das Prinzip mal kennenlernt
Mit solchen Tools kann man unterschiedliche Sachen analysieren.
Also mit diesem hier kann man Java, C plus,
C-Sharp, C-Sharp analysieren und inzwischen auch ABAP und ABAP Objects.
Aber es gibt eben auch noch ganz viele andere Sprachen,
die man da anschließen kann, wie ihr euch vorstellen könnt.
So, ich zeige euch das jetzt mal.
Könnt ihr das sehen? Kann man was sehen?
Ja, man kann was sehen. Ich kann es noch
ein klein bisschen größer versuchen zu machen. Ja, nee
, lieber nicht. So, was seht ihr hier?
Ihr seht hier ein System, das hat, mal gucken,
das hat 82.000 Lines of Code, also nicht so wirklich groß.
Ja, und nee, das ist nicht groß.
Groß ist eine halbe Million, das ist groß.
Ja, also das ist klein hier.
Auch wenn ihr sowas selber noch nicht gebaut habt,
aber das kann euch ja noch blühen.
So, und was ihr hier seht, ist der Package-Baum.
Also das ist ein Open-Source-Tool, das ist ein Customer-Management-System,
was man im Web auch findet.
Also ihr könnt das da auch runterladen, das haben wir auch gemacht.
Das heißt Infoglou, das Teil und der Package-Baum ist also org.infoglou,
CMS und dann gibt es da unter diese Verzeichnisse und dann gibt es noch zwei Parallelverzeichnisse.
Also einmal dieses da Komm, Profi,
SS3 und hier unten noch irgendein Netscape-Teil.
So, das ist erstmal der Package-Warm. Aber hier unten
sind schon so Dreiecke, ja, und die Dreiecke stehen für Files.
In Java ist natürlich jedes Fall eine Klasse, wie ihr,
ja, hoffentlich wisst. In C plus Plus ist das
anders. Da besteht eine Klasse aus zwei Files.
Deswegen ist das hier auf Pfeilebene. So, also die
Dreiecke sind files. Und wenn ich hier mal so aufklappe,
was klappe ich denn mal auf, ich kann mal nett aufklappen vielleicht,
dann sieht man da auch Klassen drin.
Ja, also unterhalb dieser Knoten verbirgt sich immer was.
Ich könnte ja zum Beispiel mal Control Solars aufklappen,
dann seht ihr unter Controllers gibt es wieder zwei Subpackages.
Und wenn ich dann auch weiter reingehe, komm wieder,
also man sieht so den Package-Baum, der sich immer weiter aufklappt.
So ähnlich wie ihr das im Explorer ja auch kennt in Windows.
So, das ist die eine Seite. Da sieht man also
die Struktur und jetzt gibt es hier rechts so lustige Bögen.
Das sind die Beziehungen zwischen den einzelnen Teilen.
Und da müsst ihr euch jetzt dran erinnern,
ich habe euch ja erklärt, wenn man was zuklappt,
dann werden die Beziehungen auf die nächst höhere Ebene aggregiert.
Und das ist hier jetzt auch passiert.
Ich könnte da jetzt mal alles zuklappen hier zu
Ja, dann seht ihr,
die Beziehung zwischen den Package-Knoten und diese Beziehung, also diese Bögen hier,
die kommen von den Beziehungen der Klassen, die da unterliegen.
So, jetzt gibt es Bögen auf der einen und auf der anderen Seite,
da gibt es hier oben so ein kleines Erklärungseigen,
könnt ihr das sehen?
Die Bögen auf der linken Seite sind Beziehungen von oben
nach unten und die rechts von unten nach oben.
Wenn man eine Schichtenarchitektur denkt, welche sind dann hier die Schlechten?
Beziehungen? Rechts die. Deswegen ist das hier in
diesem Eigen
auch rot
Bisher haben wir keine Schichtung, deswegen ist da noch nichts rot,
aber wenn man so sozusagen den eingelesenen Packagebaum von einem System sieht,
hier in diesem Tool, dann kann man meistens schon erkennen,
das ist also irgendwie schräg hier, was ich hier sehe.
So, und was man jetzt noch machen kann,
ist, man kann auch drüber fahren hier und kann gucken,
was sind das für Beziehungen. Ich weiß nicht,
ob ihr das lesen könnt, aber er schreibt da,
also das sind die Beziehungen vom Application Package da ganz oben,
runter zu dem Tree Package und das sind 138 Beziehungen von acht Pfalz
zu vier Falz und so und so viele Aufrufe und Type-Access.
Und ich klicke jetzt einfach mal doppelt hier auf diesen Bogen.
Und was dann passiert ist, dass ich diesen Ausschnitt
des Systems nur noch sehe, der diese Beziehung ausmacht.
Also ich kann mich sozusagen in das System hineinnavigieren und sagen,
ich will nur diesen Ausschnitt betrachten.
Ich will mich nur mit der Beziehung zwischen diesen Files
beschäftigen und ich kann auch noch weiter reingehen und kann,
oh, dachte ich.
Normalerweise kann man den Source-Code angucken, habe ich aber nicht richtig konfiguriert.
Also man kann sich auch den Source-Code noch angucken.
So, das ist erstmal so die Grundvoraussetzung hier.
Also man sieht die Bögen und man sieht die Elemente
So, und was wir jetzt machen wollen,
wir gehen mal wieder zu den Folien zurück.
Ich zeige euch noch mal, wie das überhaupt dazu gekommen ist,
dass man das in diesem Tool so sehen kann.
Also wie funktioniert das technisch? Technisch funktioniert das so.
Ich habe also den Java-Source. Ich starte dieses Tool und
der Source-Code und der Byte-Code, auch die werden gepasst.
Also der passt sich durch den ganzen Source- und Byte-Code und legt die Struktur,
die er da findet, ab in einer Datenbank.
Also unter diesem Tool ist eine Datenbank mit einer bestimmten Tabellenstruktur,
in der diese ganzen Beziehungen abgelegt sind
Und man kann dann mit den verschiedenen Werkzeugen auf diese Datenbankstruktur raufgucken.
Den Schritt habe ich euch jetzt nicht gezeigt, weil das relativ langweilig ist.
Da läuft nur so ein Balken lang, wenn er das System einpasst.
So. Gut, dann habt ihr erstmal eine grundsätzliche Vorstellung.
Und jetzt zeige ich euch, wie man da drauf Architektur modellieren kann.
Es ist eigentlich relativ einfach. Das sind auch die Elemente,
über die wir schon die ganze Zeit gesprochen haben.
So ein bei der Architekturmodellierung kann man eigentlich nur eine ganz begrenzte Anzahl von Dingen tun.
Man kann den Packagebaum in bestimmte Module einteilen. Also man kann sagen,
ich will ein Modul machen,
zum Beispiel ein Subsystem ist und das enthält Pakete oder ich kann Schichten machen,
das sind diese Lenksbalken hier und ich kann verschiedene Arten von Subsystemen machen,
diese Quadrate hier.
Es gibt einmal welche, die können einfach parallel liegen.
Das sind die unbestrengten Subsysteme und es gibt welche,
die dürfen sich nicht gegenseitig verwenden.
Das zeige ich euch gleich mal an dem Beispiel,
was das für Effekte hat.
Also das sind alle Ausdrucksmittel, die man hat.
Kleine Quadrate, Schichten und Salmies. Mehr gibt es nicht.
Dann kann man was sehen. So, das wollen wir
jetzt mal machen.
Flupp, flupp,
flupp, da
So, das erste, wenn ich mir jetzt vorstelle,
ich sitze da mit so einem Entwickler von diesem System und sage,
okay, jetzt wollen wir uns mal die Architektur angucken.
Wenn wir hier auf diesen Package-Baum gucken, hast du da
irgendwelche Komponenten oder Subsysteme, wie du die nennen würdest.
Und dann hätte ich vielleicht Glück und der sagt,
ja, das ist ganz einfach, alles,
was hier unter diesem Knoten ist, das sind alles Subsysteme.
Da sage ich, das ist gut,
alles einzelne Komponenten, dann mache ich die mal
zu Komponenten
Schwupp. Und dann habe ich hier diese ganzen Salmis, wie ihr seht.
Erstmal ist noch nicht viel passiert. Die sind einfach,
also die Quadrate, die sind einfach nur erst mal da.
So, und dann würde ich sagen, okay,
das ist ja schon mal fein.
Und sind die irgendwo in Schichten? Gehören die irgendwie
in Schichten zusammen? Und dann könnte das ja sein,
dass er zu mir sagt, ja,
also wir haben so eine Youthel-Schicht, die haben wir ganz unten.
Da könntest du mal Youthel, Exception, IO und nett
reintun. Ach, okay, das machen wir mal.
Plugin nicht. Okay, Plugin nicht. Also machen wir
mal einen Layer. Und den nennen wir jetzt Youthel.
So, schwupp. Dann haben wir den da oben.
Okay, was kommt denn dann für eine Schicht
Ja, also wir haben noch so eine Schicht,
die ist ganz oben, sagt er mir dann,
fällt mir gerade ein, da gehören Application und Plugins rein.
Okay, sag ich. Nehmen wir die mal und machen
eine Schicht dafür. Die heißt dann einfach mal App. So,
und jetzt seht ihr da oben einen Effekt, ne?
Seht ihr den? Da ist was rot geworden.
Das ist rot geworden, weil das sind Schichten hier.
Und die untere Schicht greift auf die obere Schicht zu.
Ja, das ist jetzt aber natürlich eigentlich gar kein Fehler,
weil eigentlich gehört die Application-Schicht über die Jutel-Schicht drüber.
Die gehören eigentlich so rum
Und dann ist wieder alles grün. Es ist erstmal wieder
alles gut. Gut. Dann sagt er,
dann sage ich zu ihm,
sag mal diese beiden hier in der Application-Schicht,
diese beiden Subsysteme da, sollen die sich eigentlich gegenseitig benutzen?
Also ist das vorgesehen das, was aus dem Application,
das Plugins benutzt? Und dann sagt er,
hoffentlich zu mir, nee, das soll nicht so sein.
Die sollen total getrennt sein. Das sollen zwei Subsysteme sein,
die sich nicht kennen. Das sind nämlich zwei verschiedene Oberflächen
von dem System. Application, hier da drin ist eine Oberfläche,
die ich alleine starten kann.
Also kann ich einfach
ein Executable ausführen oder irgend sowas
Und das Plugins, das ist was,
was man in eine andere Software reinhängen kann. So,
und die bauen alle auf dem Rest des Systems auf,
aber die sollen unabhängig voneinander sein.
Okay, sag ich, das können wir auch modellieren.
Wir können nämlich den Typ von denen hier ändern.
Wir können sie also zu unabhängigen Subsystemen machen. So,
ist nichts rot geworden, weil die Architektur richtig ist.
Ich zeige euch mal, was aber rot werden kann.
Denn hier in dem Util, in der Util-Schicht kann man sehen,
da gibt es verschiedene Subsysteme, die sich gegenseitig benutzen.
Hier seht ihr so Bögen. Ich mache die mal
zu solchen unabhängigen Subsystemen und dann seht ihr
den Effekt
Ja, da werden Beziehungen hier rot,
und zwar genau die Beziehung zwischen diesen Modulen in dieser Schicht.
Die werden rot. Denn wenn ich sowas, das so modelliere,
dann will ich ausdrücken, dass die sich gegenseitig nicht kennen dürfen.
Und wenn ich eine wirklich gute Architektur habe,
dann habe ich häufig bei größeren Systemen Schichten,
in denen ich einzelne Komponenten drin habe,
die sich eben nicht gegenseitig benutzen sollen.
Hier bei einem Jutel ist das jetzt offensichtlich nicht so und dann glaube ich,
dass dem Entwickler auch und mache das mal wieder zurück.
Also ich habe jetzt bisher in der Architektur Sachen ausgedrückt,
wo die ist Architektur tatsächlich dem Plan entspricht. Ja,
also es ist wirklich so, er hat mir,
er hat mir das erzählt, Applikation, Application und Plugins,
sie sollen sich gegenseitig nicht kennen.
Und das stimmt auch, denn wir haben hier keine Beziehung
dazwischen und keine roten Bögen, wie ihr seht.
So, jetzt könnten wir hier so weiter modellieren,
aber ich bin jetzt mal in dieser Sekunde faul und lade mal eine Architektur,
die ich schon fertig habe für den ersten Schritt.
So, das ist doch schon sehr hübsch.
Ich zeige euch mal, was hier passiert ist.
Das ist das, was wir eben zusammen modelliert haben.
Wir haben also eine Schicht gemacht mit diesen zwei unabhängigen Subsystemen
da drin.
Util hatten wir
auch modelliert
Und ich habe vorher dann schon eine Schicht gemacht für
das Entities-Subsystem und eine für Services.
Da sind die vier anderen drin. So,
und jetzt sieht es ja schon ziemlich bunt aus hier.
Und ich zeige euch mal, was da passiert ist.
Eine Sache muss ich nochmal eben zurückmachen hier. Die habe
ich hier schon vorher gemacht. Guckt mal eben weg.
So, weg. Das erzähle ich euch gleich noch.
So, was ihr jetzt hier seht,
mach es mal wieder zu, sind vier Schichten.
Das System besteht aus vier Schichten.
Und ihr seht ganz viele schöne grüne Bögen
So ein ganz paar rote. Also ich würde an
der Stelle zu den Softwareentwicklern von diesem System immer sagen,
ihr habt aber gute Arbeit geleistet.
Ihr habt nur ganz wenig Schichtverletzungen. Es ist gar nicht
so schlimm, ja, wie ihr vielleicht denken würdet.
Hier sind so ein paar, gucken wir mal,
wie viele Beziehungen sind denn das?
24 Beziehungen zwischen fünf, einmal fünf Files nach zwei Files
und hier sind auch drei Files nach fünf Files.
Also eigentlich ist es nicht so wirklich, wirklich viel Schlimmes.
Ja, viel, viel Grünes ist auf der anderen Seite.
Das muss man den Leuten dann
immer erst mal sagen
So, was ich dann machen würde, ist,
dass ich mit den Leuten anfange, diese Verletzungen zu untersuchen.
Ja, wir können ja jetzt mal hier oben diesen Bogen
hier untersuchen mal und gucken, was da eigentlich falsch ist.
Ja, klicken wir mal da drauf. So,
und dann sehen wir hier,
dass hier unten so ein paar Klassen sind, ja,
die benutzen alle, das geht der Bogen nach oben hier,
einen Visual-Vormitter und noch so ein anderes Ding da oben.
So, und was man jetzt mit diesen Tools ganz hervorragend machen kann,
ist, dass man kann ausprobieren,
was würde es denn für die Architektur bedeuten,
wenn ich
einen Fehler repariere
Also ich kann jetzt hergehen und kann sagen, ja,
was würdet ihr denn machen, um den Fehler zu beheben hier?
Was könnte man tun? Hier sind Beziehungen von unten nach oben
. Was muss man machen, damit diese Fehler wegkommen?
Was kann man tun? Testen ist die falsche Antwort jetzt
gerade. Was könnte man machen? Um die Fehler loszuwerden
. Eine Idee? Nee. Was man machen kann,
ist,
man kann umsortieren
Also man könnte doch, also ich meine,
hier gibt es jetzt diese Bögen, ja,
dann nehme ich doch das Teil und tue es da unten hin.
Dann sind die doch weg. Ist das eine gute Idee?
Ja. Ist das eine gute Idee oder was könnte... Genau,
wir wissen im Moment noch nicht, was uns noch blüht,
wenn wir diese Klasse da verschieben.
Also das ist genau das, was du sagst.
Und in die Richtung würde ich jetzt auch gehen und kann euch noch was zeigen,
weil wenn ich diese Klasse jetzt verschiebe hierhin, weiß ja gar nicht,
aus diesem Bild, was die sonst noch so tut,
ja, mit wem die sonst noch so zu tun hat.
Das kann man aber nachsehen. Ich kann nämlich sagen,
zeig mir mal alles, was der, wer,
wen der noch sonst so kennt, ja.
So, jetzt sehe ich hier in diesem Bild,
ich schiebe das nochmal ein bisschen rum, hier,
damit das ein bisschen größer wird.
Jetzt sehe ich also, die Klasse will ich verschieben,
ja, nach hier unten.
Und wenn ihr euch das Bild so anguckt,
dann seht ihr alle Beziehungen, die die hat,
geht das oder geht das nicht
Das einfache Graphentheorie, ich zeige es euch mal.
Es geht, ne? Denn alle Bögen, die da zu ihm hingehen,
die kommen von oben, die sind alle grün.
Ich lasse das jetzt mal da hinfallen, so.
Ja, seht ihr, der ist jetzt hier unten,
der hat so ein R, das kann man wahrscheinlich nicht sehen.
Ich mache ihn mal groß. Da,
so ein kleines R. Der ist also restrukturiert.
Ich habe also jetzt was umgebaut. Und es sind kein,
mit dieser Klasse zumindest keine roten Bögen mehr da.
Die habe ich aufgelöst,
die Verletzung hier
Wenn ich sowas das erste Mal mache und da sitzen Entwickler
von so einem System dabei, dann sagen die immer,
haben sie das jetzt in echt gemacht auf unserer Software?
Und dann sage ich immer, nein, das würde ich
ja niemals tun. Sie müssen doch erst noch ihre ganzen
Tests laufen lassen und dafür einen Test schreiben und so weiter.
Gar nicht. Aber sie kriegen nachher aus dem Tool einen Ausdruck,
was sie alles umbauen müssen. Wenn man das dann so fünf,
sechs Mal gemacht hat, dann sagen die Leute immer,
können sie das nicht gleich auch richtig auf unserem System machen?
Aber das geht natürlich nicht. Das ist auf der Datenbank
von diesem Tool. Also es ist nicht in Eclipse
oder irgendwo. Man muss das dann noch nachziehen.
Das ist ja auch
nur ein Ausprobieren
So, wenn wir jetzt wieder zum Originalbild gehen,
sieht es immer noch so aus, aber hier sind weniger Beziehungen drin.
Es sind nur noch 15 und nicht die vielen, die wir vorher hatten.
Also so kann man mit den Leuten das aufräumen, ja,
ihre Software, damit sie, die Istarchitektur, der Sollarchitektur mehr entspricht.
Und die Sache, die ich vorhin gerade weggemacht habe und
die ich euch gleich noch zeigen will, ist etwas,
was ihr wahrscheinlich nur im Kleinen bisher kennt.
Wenn ihr Klassen programmiert, dann bin ich sicher,
dass Axel mit euch ganz viel über Schnittstellen spricht.
Also was ist die Schnittstelle von der Klasse
Was für Methoden sollen da rein oder sagt ihr Operationen dazu?
Also wie sind die, ist die Schnittstelle einer Klasse?
Das setzt sich natürlich auch auf höheren Ebenen von Softwaresystemen fort.
Wenn man an eine Komponente deckt oder an eine Schicht,
dann ist auch immer die Frage, was ist die Schnittstelle derselben?
Also wenn ihr, also meine Erfahrung ist so ungefähr bei Systemen,
die eine halbe Million Lines of Code groß sind,
fangen die Leute an, exzessiv Schnittstellen zu bauen.
Deswegen findet man in diesem kleinen System hier auch noch nicht wirklich welche,
aber ich versuche euch mal eine Stelle zu zeigen,
wo man sich vorstellen könnte, dass man eine Schnittstelle definieren wollte.
So, diese, oh, das war doof,
jetzt hab ich das, da seht ihr die ganzen Klassen da drin.
Also, dieser Knoten hier, ne, seht ihr,
der heißt Colonel Impel, ja, also wenn man auf Software-Systeme guckt,
dann findet man häufig Package-Knoten, die Impel heißen.
Oder wenn ihr mal in Eclipse reingeguckt habt,
in die Klassen, die da drin sieht,
dann findet ihr eine Clips in den Komponenten immer ein verzeihenes,
was Impel heißt.
Und eins, was API, also Schnittstelle heißt,
ja, also die versuchen ihre Package-Bäume auch so zu strukturieren,
dass man die,
dass man Schnittstellen wiederfindet
Hier in diesem System, wenn wir uns mal vorstellen,
der, der das hier gebaut hat, hat sich gedacht,
dass das Impel-Ding eigentlich von außen nicht verwendet werden soll.
Dann könnte ich hergehen und könnte das Ding privat machen.
Und bevor ich das mache, guck mal hin,
der hat natürlich Beziehungen nach außen.
Die sind jetzt alle grün. Und wenn ich den jetzt
zu einem, wo ist es denn?
Blue Blue, da. Zu einem privaten Teil mache,
seht ihr, werden Beziehungen rot. Also alle Beziehungen,
die reingehen in diesen Knoten, sind dann eigentlich verboten.
Eigentlich sollen die anderen Schichten hier oben oder anderen
Subsysteme diesen Teil nicht benutzen
Innerhalb von so einer Komponente ist das natürlich erlaubt,
sonst hätte ich ja ein großes Problem.
Ich muss ja für eine Komponente eine Schnittstelle bauen und den
privaten Teil. Aber die müssen sich natürlich gegenseitig verwenden,
weil sonst würde der die Schnittstelle gar nichts machen können.
Also für diese Architektur her ist es relativ unsinnig,
dass sie das Ding Impel genannt haben.
Aber ich würde das dann in der Architektur sehen können,
auf der linken Seite, wenn da was rot ist,
habe ich Schnittstellenverletzungen.
Ja, da wird sozusagen die Schnittstelle durchbrochen von einer Schicht.
Und das Unangenehme, wenn man einfach nur Java programmiert,
ist, dass man sowas im Packagebaum nicht ausdrücken kann.
Ja, man braucht also entweder in Eclipse-Komponentenmodelle dazu oder
man braucht solche Tools, um das zu überprüfen.
Und hier kann man
das machen
So, jetzt kann ich euch noch eine interessante Sache zeigen,
stellen wir uns mal vor, dieses System wäre so gedacht,
dieser untere Teil hier läuft irgendwo auf einem Server,
ja, und der Application-Teil läuft irgendwo anders, ja,
und ich will sozusagen, dass der Application-Teil nur diese Service-Schicht benutzt,
also nicht die anderen hier unten, ja,
dann könnte ich hergehen und könnte sagen,
ich will diesem Teil hier sagen,
dass es nach unten nur eine Schicht zugreifen darf, ja,
es darf also nur eine nach unten greifen und dann seht ihr,
Nee, eine muss ja richtig sein.
Dann habe ich das Falsche eingetragen. Mach mal Steuerung Z. Ach so,
jetzt weiß ich, warum, nochmal Steuerung Z. So. So,
jetzt sind wir wieder in dem Ausgangszustand und es gibt in Architekturen oft so Fälle,
dass man ausdrücken will,
eine Schicht darf nur die nächstuntere benutzen und die daunter aber nicht mehr,
ja, um eine Strenge, das nennt sich strenge Schichtung,
um sowas herzustellen.
Und das mache ich jetzt mal hier. Ich sage also diesem Ding,
es darf nur eine Schicht runter, ja,
und was jetzt passiert ist,
die Beziehung einen runter ist grün,
ja,
könnt ihr das sehen
Und die Beziehungen zu den anderen Schichten, darunter ist rot.
Ja, also das heißt, ich darf aus dieser Application-Schicht eigentlich
nur einen runter und nicht noch in die anderen Schichten da untergreifen.
So kann man solche Sachen ausdrücken. Hier für dieses System
ist das nicht sinnvoll, weil ihr das ja seht,
dass die Application-Schicht ganz exzessiv auf die Entities zugreift und auch auf das Hu-Till-Package da unter.
Deswegen mache ich das mal wieder zurück und wir haben wieder
unser Bild von vorher.
So, gut
Wir haben uns jetzt hier diese Verletzung angeguckt. Wir haben uns angeguckt,
dass wir Schichten machen können und dass wir in den Schichten
wiederum die einzelnen Subsysteme haben können. Habt ihr gesehen,
dass wir sowas ausdrücken können wie in einer Schicht will ich
getrennte Subsysteme haben, die sich nicht gegenseitig kennen.
Sowas will ich in Architekturen ausdrücken. Und dass ich auch
was dazu sagen kann, wie viele Schichten runter eigentlich ein Teil
einen anderen benutzen soll. Das ist besonders wichtig,
genau dann, wenn ihr so eine Architektur habt,
wo ihr einen Teil auf einen Client und den anderen auf den Server tut,
Habt ihr eine Schicht dazwischen, die beide kennen?
Ja, der Client und der Server, um miteinander zu kommunizieren.
Aber über diese Schicht soll die oberste Schicht nicht hinausgreifen.
So, das gucken wir uns jetzt nochmal an in einer
Grafik so ein bisschen zum Vergleich. Also,
wir sind davon ausgegangen, wir haben eine Sollarchitektur,
wir haben also irgendwo ein Bild oder die Leute haben es
im Kopf,
wie ihr Softwaresystem aufgebaut ist
Ich habe euch hier mal ein vereinfachtes Bild hingemacht,
so was, was ihr eben schon gesehen habt.
Stellen wir uns vor, unsere Software ist so aufgebaut.
Wir haben zwei Schichten, eine untere und eine obere Schicht.
Die untere Schicht hat zwei Subsysteme, hier diese beiden, die obere auch.
Und da sind jeweils Packages drin oder auch nochmal Subsysteme.
Und ich habe einige so beige gefärbt, um auszudrücken,
das ist die Schnittstelle jeweils.
Das heißt, dieses größere Teil hier kann man nur,
darf man nur über diese beiden hier benutzen.
Und dieses größere Teil nur hierüber. So,
jetzt stellen wir uns vor, wir haben die Ist-Architektur analysiert
Und finden das Bild. Ja,
also wir finden dieses Bild in der Software.
Erstmal ganz gut. Sieht ja ganz ähnlich aus, fast jedenfalls.
Also wir haben hier unten eine Schicht und eine obere Schicht.
Wir haben auch hier Beziehungen. Hier fehlt eine. Hier
ist ein System, Subsystem extra, das fehlt da.
Aber erstmal sieht es schon ähnlich aus. Das ist bei
kleinen Systemen auch ganz, also bei vielen Systemen auch häufig
schon gar nicht der Fall.
Da hat man viel mehr Kraut und Rüben.
Jetzt fehlt hier eine Beziehung, die fehlt hier,
wo ist sie hin? Und hier fehlt irgendwie ein Subsystem
. Das fehlt. So. Wenn eine Beziehung fehlt,
könnte man ja sagen, na, mach doch nichts.
Die fehlt halt. War nicht notwendig. Könnte man sagen
. Aber wenn man sich das genau anguckt, könnte man
sich auch vorstellen, hier ist ja was extra hinzugekommen.
Dass die Softwareentwickler eigentlich was von dieser Komponente hier unten verwenden sollten.
Aber was haben sie gemacht? Sie haben das kopiert da oben hin.
Ja? Die haben einfach eine Kopie gemacht und deswegen habe
ich jetzt duplizierten Code oder eben Redundanz in meinem System.
Ja, das ist ein häufiger Grund dafür,
dass irgendwelche Beziehungen fehlen, die man sich mal gedacht hatte.
Ja, und irgendwas ist extra da. Ja,
also wenn irgendwas fehlt, muss man sich auch auf die Suche machen,
was ist passiert. Hier fehlt zum Beispiel ein Subsystem,
da könnte man die Leute auch fragen, wo ist es geblieben?
Was habt ihr gemacht? Habt ihr es woanders untergebracht?
Ist es hier mit drin? Ja, was ist passiert?
So, dann gucken wir mal die nächste Möglichkeit an.
Wir stellen uns vor, wir finden in der Ist-Architektur solche Beziehungen,
wie die, die hier rot eingemacht angemalt habe.
Das sind Architekturverletzungen
Also der war nicht geplant, aber dieser hier ist ganz
schlimm, ne? Seht ihr das? Das ist nämlich
eine Schichtenverletzung, eine Beziehung von unten nach oben.
Das waren die Pfeile, die eben auch in dem Tool
rot fahren. Ja? Also das kann man finden,
solche Architekturverletzungen, wenn man soll und ist Architektur vergleicht.
Und was kann man noch finden? Das war das Letzte,
was wir eben gesehen haben. Die Pfeile sind alle ein
bisschen verrutscht, ne? Der ist ein bisschen zu tief.
Man kann Schnittstellenverletzungen finden. Also dieses Modul hier oben greift an
der Schnittstelle vorbei auf irgendein interner, von dieser Komponente zu.
Und hier passiert das
auch nochmal
Das sind eigentlich die Dinge, die man mit so einem Soll-Ist-Vergleich in Software-Systemen finden kann.
Was anderes kann man eigentlich nicht finden. Man kann finden,
Verletzungen von bestimmten Zugriffen, die man gemacht hat,
Verletzungen von Schnittstellen und dass irgendwelche Sachen nicht da sind,
die man erwartet hatte. Das ist immer ein lustiges Spiel,
wenn man die Leute fragt, wie ist denn die Architektur?
Manche haben ein Bild, einen Plan, einen Zettel,
manche haben es nur im Kopf und dann festzustellen,
okay, die Vorstellung, die die hatten,
passt gar nicht zu dem, was sie nachher gebaut haben.
Oder umso schöner sie passt dazu. Ich finde also,
soll und ist Architektur passend zusammen. Es kommt natürlich auch immer wieder vor,
dass man mit Leuten redet, die haben gar keinen Plan.
Ja, da gibt es keine Sollarchitektur, sondern es gibt
nur das Ist. Also es gibt nur das,
was die Leute bauen, dann ist es ganz schwierig.
Dann fängt man sozusagen hinterher an, sich was für die Leute auszudenken.
Wie könnte man dieses System strukturieren? Das ist wirkliche Arbeit mit den Leuten,
das überhaupt erst mal klar zu machen, man könnte Schichten haben,
ja, warum sollte man denn Schichten haben?
Man könnte Schnittstellen haben, darüber kann man dann viel diskutieren.
Und was ganz viel Spaß macht, das nennt sich Software-Archäologie.
Also sozusagen, man kriegt ein System und es gibt niemanden mehr,
der weiß, wie die Architektur sein sollte.
Und dann wird man zum Archäologen und wühlt da drin
herum und versucht herauszufinden, was die Idee war.
Das wird sicherlich auch einer eurer Job sein,
denn das wird jetzt mehr und mehr vorkommen.
Ich habe euch ja schon erzählt, die Systeme,
die wir 99 angefangen haben, zu bauen,
da sind die Architekten nicht mehr da.
Also die, die das gemacht haben. Die sind in
einem Zwischen, haben andere Jobs. Das ist nach zehn
Jahren auch ganz normal. Also stellt man intelligent intelligente,
aufstrebende Studenten ein und lässt die das System untersuchen und irgendwelche
schönen Diagramme davon machen und hofft, dass sie was darüber rausfinden.
Oder was lässt man sie noch machen, die jungen Spannenden interessierten Studenten?
Das ist wieder die Standardantwort, man lässt sie Tests schreiben
für ein System, was man nicht kennt, natürlich.
Gut, also sollte in der Klausur die Frage stehen,
was kann man für Fehler in der Architektur finden, wenn man Architekturanalyse macht,
dann solltet ihr euch Wupp an dieses Bild erinnern und die vier Punkte runterbeten können.
Also oder die drei, die Fehler, die man finden kann.
Gut. Um den ganzen Prozess nochmal mit euch zu betrachten,
habe ich euch noch diese Folie mitgebracht.
Was passiert eigentlich bei der Mitarchitektur und mit der Analyse von Architektur?
Es gibt, wenn die Software geplant wird, gibt es irgendwelche Anforderungen.
Jemand macht einen Entwurf dafür. Das sind meistens irgendwelche technischen Anforderungen,
wie wir brauchen verschiedene Clients, wir brauchen Performance,
wir brauchen dies oder das. Ja,
also es wird ein Architekturentwurf gemacht und eine Sollarchitektur,
die in der Regel aus einer Zerlegung in irgendwelche,
ich sag jetzt mal, Subsysteme,
irgendwelche Teile besteht und man spezifiziert die Abhängigkeiten und Schnittstellen.
Das ist genau das. Ich gehe nochmal zurück, was
ihr hier eben gesehen habt. Ja, also ich spezifiziere,
welche Teile es geben soll und wie die miteinander zu tun
haben sollen und was für Schnittstellen es da geben soll.
Mehr kann man bei Architektur nicht machen. So,
und dann wird das gebaut, ja,
das wird dann gebaut und dann kommen wir mit dem Tool,
ja, da an und sagen, okay, gebt uns mal den Code
Und dann erzählt uns doch bitte auch noch,
wie der Plan zu dem Code passen soll.
Wenn ihr eben meiner Geschichte gelauscht habt, wie ich erzählt habe,
wie ich mit jemandem, der dieses System da gebaut hat,
ich gehe da noch mal hin.
Also mit jemandem, der diese Software gebaut hat,
davor sitze und dann sage, okay, was hast du denn hier für Einheiten?
Dann ist das im Grunde der Schritt,
dass er mir ja sagen muss, wie sein Package-Baum,
ich hole noch mal den Package-Baum zurück.
Ja, wir haben hier den Package-Baum. Wie passt der
denn jetzt zu dieser Architektur? Ja, wie gehören der
Package-Baum und die Architektur zusammen
Das ist hier auf der Folie mit Abbildungsvorschrift gemeint. Wie sind die Subsysteme im Code repräsentiert,
die ich da mir oben ausgedacht habe,
werden diese Abhängigkeiten eingehalten, werden die Schnittstellen,
wo sind die, ja, das alles rekonstruiere ich,
ja, wenn mir das jemand erzählen kann,
dann habe ich die Ist-Architektur und dann vergleiche ich das beides und kriege eben eine Differenz zwischen den beiden.
Also ich kriege Verletzungen und ich finde Übereinstimmung und was man dann am Ende
von so einer Untersuchung in der Regel macht, ist,
dass man sich mit den Leuten hinsetzt und Maßnahmen definiert. Also dass man dann sagt,
okay, wenn ihr die Architektur verbessern wollt,
dann müsst ihr jetzt als erstes mal hier so ein bisschen aufräumen,
so was, was wir vorhin gemacht haben, ja,
dass Flüchtigkeitsfehler erstmal ausgeräumt sind, ja, denn das Übliche ist,
dass wenn man auf so eine Architektur das erste Mal mit so einem Tool guckt,
ist, dass man ganz viele Flüchtigkeitsfehler findet, ja,
die Leute haben irgendwas kopiert und beim Kopieren haben sie es nicht umbenannt und es ist woanders geblieben oder sie benutzen irgendwas.
Ich meine, ihr werdet bestimmt auch schon in Eclipse die schöne Erfahrung gemacht haben,
dass man einen Klassennamen eintippen kann, von einer Klasse,
die auch irgendwo anders ist,
also nicht in demselben Package,
wo ihr seid und dass dann Eclipse automatisch oben reinschreibt,
das importieren wir jetzt mal aus dem und dem Package
Dass ihr das seht. Ja, ihr könnt dann bei Ineclipse irgendwo auf Return drücken und schwupp,
ist das Ding importiert, ja. Das ist natürlich,
damit ist natürlich Tür und Tor geöffnet,
dass die Leute irgendwas importieren, irgendeine Klasse,
an die sie sich erinnern, automatisch,
ohne das selbst eingetippt zu haben und gemerkt zu haben,
dass sie aus einer unteren Schicht jetzt plötzlich eine obere benutzen,
ja, weil das gar nicht so auffällt.
Das geht einfach sehr schnell, ja,
dass man eintippt, oh, dann, ne,
dass man sowas eintippen würde wie, ich bin jetzt,
ich bin mal wieder meine Schichten haben,
hole ich die nochmal zurück
So, ich habe jetzt hier meine Schichten und ich programmiere
hier unten in irgendeiner Klasse in Youthill, ja,
in den Clips und dann schreibe ich rein, oh,
ich brauche irgendwie was von irgend so einer Hilfsklasse,
die hier drin ist,
aber ich brauche nur den Namen hinzuschreiben von der Klasse und Eclipse importiert mir das automatisch.
Und schon habe ich eine Architekturverletzung eingebaut, ohne dass mir das bewusst geworden ist. Ja,
das machen Menschen natürlich ganz viel, wenn sie entwickeln,
weil sie wollen schnell ihr Problem lösen und sie wollen ja während der Entwicklung nicht hauptsächlich die Architektur erhalten.
Ja, das ist, das ist nicht im Fokus. Deswegen findet man am Anfang,
wenn man das das erste Mal macht, Immer,
immer, immer, ganz viele Verletzungen,
die relativ die Flüchtigkeitsfehler oder aus Versehen oder wir haben einfach nur mal,
ja, da muss man den Leuten auch echt,
muss man freundlich mit ihnen umgehen, ja,
also je nachdem, was man verkaufen will, ne,
wenn man ganz viele Leute verkaufen will,
die bei denen die Software wieder heile machen,
da muss man natürlich die ganze Zeit, oh, oh,
oh, sagen oder sowas, ja, aber wenn man ehrlich ist, dann ist es da nicht so.
Die Leute haben an ihrem System gearbeitet,
um was fertig zu kriegen und jetzt räumen wir mal auf,
ja, und es ist immer gut,
wenn man das nicht zu spät macht, ja,
wie bei jeder Softwareentwicklung, wenn man bis ans Ende wartet,
dann hat man ganz,
ganz viel zu tun und die Maßnahmen werden auch komplizierter
Ich habe vorhin diese eine Klasse da einfach mal verschoben,
das war eine ganz einfache Maßnahme, die kann man den Leuten einfach aufgeben,
aber wenn sie wirklich Beziehungen aufbrechen müssen,
kann euch nochmal den anderen Fall zeigen,
wir haben ja jetzt da vor und ein bisschen aufgeräumt,
wir haben uns ja mit dieser Beziehung hier beschäftigt,
ja, den hatten wir einfach so verschoben,
nach hier, war alles gut, ja,
den da können wir nicht so leicht verschieben.
Ich zeige euch mal, was der noch so für Beziehungen hat.
Ja, also das ist zu groß. Die Klasse hier,
wird von unten benutzt, ja,
aber die wird hier auch benutzt und von hier und benutzt,
naja, vielleicht können wir die doch verschieben,
wo wir mal gucken, was passiert?
Oh, geht doch. Tun wir mal. Ah,
nee, eben nicht, ne? Jetzt benutzen nämlich,
also nee, das liegt aber an dem Private,
das machen wir mal weg.
Das ist doch schön, das geht.
So, also die konnten wir auch verschieben, wunderbar.
Dann sind wir ja den roten Bogen weg losgeworden, den einen.
Gucken wir mal was anderes. Können wir hier irgendwas?
So, hier könnten wir mal gucken. Also hier gibt es
auch so Beziehungen von hier unten nach oben und ich glaube,
wenn wir die Klasse hier verschieben,
gibt es auf jeden Fall Probleme,
mal mal schauen
So, wenn wir die verschieben, was geht auch?
Ich habe ja heute echt Pech, ich finde nichts, was nicht geht.
Schwupp, das geht, haben wir noch viel Rotes?
Na gut, aber ihr könnt euch vorstellen, dass es
auch mal Fälle geben kann, wo es nicht geht.
Ja, wo man einfach nichts verschieben kann, weil anderes dann rot wird.
Ja, ich kann auch ein bisschen suchen,
weil gleich machen wir Pause, ich gucke nochmal,
ob es hier noch was Schönes gibt.
Vielleicht gibt es da was, was, ja,
wenn ich den jetzt Nach hier unten seht ihr das,
diesen hier, ja, ja, geh mal weg.
Diese Klasse hier, User-Control-Proxy, wenn ich die verschiebe,
nach so weit unten, wie ich sie verschieben müsste,
nämlich nach hier, dann werden diese ganzen grünen Beziehungen,
die sie da rechts hat, rot.
Pass mal auf, schwupp, jetzt ist das alles rot.
Ja, das war also keine gute Idee.
Huch, so. Keine gute Aufräum-Idee. Ich mache das
mal wieder zurück. Ja, diese eine rote Linie,
da wollte ich loswerden, die da.
Und wenn ich die nach unten schiebe,
um die loszuwerden,
entstehen ganz viele neue
Also das ist nichts, was man einfach mal aufräumen kann.
In diesem Fall muss ich mit den Leuten die Klassen angucken,
die da beteiligt sind und muss mit den Leuten tatsächlich das Design überarbeiten.
Das ist ein viel schwierigeres Problem. Und da ist tatsächlich
ein Architekturproblem. Das ist nicht nur ein,
wir räumen mal hier so ein bisschen eben auf Problem.
Gut, also was ihr davon mitnehmen sollt, ist,
wir werden immer Fehler finden.
Ja, wir werden immer Differenzen finden,
gerade wenn wir das das erste Mal machen.
Aber auch wenn wir das zweite Mal machen,
weil die Leute zwischendurch einfach einen ganz anderen Fokus haben in
der Entwicklung
Je früher man das macht, desto weniger gravierend werden die Maßnahmen
sein, die man ergreifen muss. Wenn die Maßnahmen,
wenn man hier das sehr spät macht in der Entwicklung,
also wenn wir jetzt unsere Systeme angucken würden,
die von 1999 sind und die noch nie mit dem Tooler draufgeguckt hätten,
dann würden wir sehr viele Verletzungen wahrscheinlich finden.
Und die Maßnahmen würden auch ziemlich aufwendig sein. Deswegen ist es
auch so teuer, alte Software wieder in den Griff zu kriegen.
Neben der ganzen Archäologiefrage. Es ist viel besser,
das früher zu machen. Aber ich glaube, das mit
der Softwarevorsorge, das haben noch nicht so viele Leute verstanden.
Jetzt geht's gleich. Jetzt haben wir diese beiden Punkte geschafft hier.
Wir haben uns also mit der Architekturanalyse beschäftigt und gleich werden wir
uns noch ein bisschen für mit Messungen in Softwaretechnik beschäftigen.
Und da machen wir vorher eine kleine Pause.
Dann geht's gleich weiter. So. Jetzt wollen wir uns noch
ein bisschen mit dem Messen beschäftigen.
Das kennt ihr schon,
die Norm über Qualitätsmerkmale
Wenn ich mir vorstelle, ihr sitzt nachher in eurem Unternehmen
und euer Chef sagt zu euch, so, nun,
Sie können doch jetzt mal, Sie sind doch Informatiker,
Sie wissen ja, wie man Software baut.
Jetzt stellen Sie mal fest, in was für eine Qualität
unsere Software hat. Was macht ihr denn dann?
Tja, das ist die Frage. Also ich meine,
so ein Chef könnte ja mit sowas ankommen,
würde mich auch nicht wundern, wenn er das tut.
Und dann hoffe ich, dass ihr euch an ein paar
Dinge erinnert, die ihr hier gehört habt, nämlich,
dass es Modelle für Softwarequalität gibt.
Eins davon ist dieses
Da steht oben drüber das Ziel. Man will also
externe und innere Qualität in einem Softwaresystem haben.
Und dann gibt es da drunter verschiedene Faktoren,
wie man diese Qualität, was das eigentlich bedeuten soll.
Weil ich meine, die Aussage, sagen Sie mir mal
was über die Qualität unserer Software, ist ja unglaublich unscharf.
Ja, was soll man denn darauf antworten?
Andererseits ist man der Softwarearchitekt und soll dann darauf antworten.
Ja, so, dann muss man sich mit irgendwelchen Details
dazu ausstatten, um solche Antworten geben zu können
Das würde ich euch an diesem Qualitätsmodell, an dem,
was jetzt gleich noch kommt, so ein bisschen zeigen,
wie schwierig das ist und welche Möglichkeiten man eigentlich hat.
Also wenn euch jemand nach Qualität von Software fragt,
dann gibt es ganz viele verschiedene Faktoren,
die diese DIN-Norm schon mal vorschlägt,
um die man sich da kümmern kann.
Man kann sich fragen, wie ist die Funktionalität von dem Softwaresystem?
Also tut es das, was es soll?
Das ist ja schon eine wichtige Frage. Erfüllt das Softwaresystem
die Anforderungen, die man alles hat? Ist es sicher,
also gehen keine Daten verloren, können die Anwender es überhaupt benutzen,
eignet es sich zu dem, was die Anwender wollten?
Ja, all diese Fragen kann man sich stellen.
Das ist dann das eine,
aber zum Beispiel habe ich euch ja immer wieder von meinem Container-Terminal erzählt,
wo ich da arbeite,
da ist die Zuverlässigkeit eine unglaublich wichtige Frage
Ist das System fehlertolerant? Was macht es,
wenn irgendwelche Daten nicht über die Schnittstellen transportiert werden?
Kann es damit umgehen, wie ausfallsicher ist es,
im Grunde die Frage nach seiner Zuverlässigkeit?
Ja. Nächste Woche wird mein Kollege Hartmut Obendorf zu euch
kommen und wird euch was über diesen nächsten Faktor da erzählen,
über die Benutzbarkeit, über Usability von Softwaresystemen?
Kann man das lernen? Kann man es bedienen?
Ist das attraktiv? Ja, ich würde bei
attraktiv immer gleich an ein iPhone oder sowas denken.
Also ist es hübsch? Ja, kann man es benutzen
? Macht es Spaß? Ist es verstehbar, erlernbar
Aber wenn man auf die Frage eine gute Antwort hat,
ihr könntet zu eurem Chef ja sagen,
die Qualität der Software ist total klasse,
weil alle finden es total attraktiv.
Also es macht Spaß, damit zu arbeiten.
Man kann es lernen und so. Kann genauso gut sein,
dass es dann woanders sehr zeitintensiv ist oder sehr viel Ressourcen verbraucht.
Also wir müssen, aber damit das so attraktiv ist,
müssen wir die teuersten und schnellsten und immer wieder besten Rechner besorgen.
Ja, das wird auch dann irgendwann sehr teuer.
Also Ressourcennutzung und Zeitverhalten hat auch was mit Qualität zu tun.
Und dann kommt aber der Softwareentwickler und sagt,
also interessiert mich alles nicht
Entscheidende. Für mich ist, dass das System wartbar ist.
Ja, also das ist das alles Entscheidende. Oder der
Nächste kommt und sagt mir, für mich ist die Portierbarkeit wichtig.
Über welche von diesen Faktoren da, von diesen Merkmalen,
habe ich mit euch bis jetzt immer hauptsächlich gesprochen?
Wenn ihr so leise sprecht, kann ich nichts verstehen.
Habe ich mit euch über Effizienz von Softwaresystemen gesprochen?
Ich habe euch gerade den Kollegen für nächste Woche angekündigt zur Benutzbarkeit.
Also habe ich euch wohl auch nichts davon erzählt, ne?
Außer so mal immer mal. Zuverlässigkeit? Ja, habe ich
immer mal was erzählt. Funktionalität hat Guido euch mehr darüber erzählt.
So Anforderungsermittlungen und sowas, da hat Guido euch was zu erzählt.
Also jetzt bleibt nicht mehr viel übrig, ne?
Ich habe mit euch über so Sachen gesprochen,
wie ist das Ding änder, ist es stabil,
ist es änderbar, erweiterbar, analysierbar.
Also wie ist die Wartbarkeit, ne? Wir haben uns
die ganze Zeit mit statischer Architektur und sowas beschäftigt, ja?
Was sind gute, ne, erinnert ihr euch,
Entwurfsmuster oder Architekturstiele, ja, für ein Softwaresystem,
Schichten, all so ein Zeugs,
ja?
Also um das haben wir
uns viel gekümmert
Gut, also wir hatten unseren Fokus auf Wartbarkeit.
Aber messen kann man das alles oder sagen kann man über all das, was?
So, nun stehen da so Sachen wie Änderbarkeit. Ja,
also ihr könntet ja an eurem Chef eine Mail schreiben und könntet uns schreiben,
lieber Chef, für mich ist Qualität, dass die Software änderbar ist,
dass sie, keine Ahnung, bedienbar ist, ausfallsicher.
Und dann sagt euer Chef,
das nützt mir immer noch nichts, ich will ein Diagramm,
damit ich mal im Vorstand was vorlegen kann,
wie toll unsere Software ist.
Also es bleibt euch nichts anderes übrig,
als irgendetwas zu messen.
Wie kommt man jetzt dahin
Halt, hier geblieben. So,
es gibt also eine Methodik, dass man versucht,
Qualitätsmodelle so zu beschreiben, dass man sagt,
es gibt ganz oben das Ziel, was man hat,
Softwarequalität, dann gibt es Faktoren,
ja, häufig auch Merkmale genannt,
die ihr eben gesehen habt und dann gibt es zu diesen Merkmalen wieder Teilmerkmale und die werden dann zurückgeführt auf Qualitätsindikatoren, also tatsächlich auf Metriken.
Aber in der Regel eben nicht, jeweils nur auf eine,
ja, ich gehe nochmal zurück, es gibt,
hallo, es gibt nicht ein Maß,
um die Analysierbarkeit eines Softwaresystems zu messen
No way. Es gibt auch nicht ein Maß für
die Qualität an der Software. Also eine Zahl.
Bei Hotels ist das ja so hübsch, oder?
Ihr kennt doch auch dieses mit den Sternen, ne?
Eins bis fünf Sterne. Das ist ein Versuch, ja?
Aber wirklich funktionieren tut es natürlich nicht. Also ich meine,
klar, wenn man im Fünf-Sterne-Hotel ist, dann weiß man,
dass es da sicherlich besser ist als im Ein-Sterne-Hotel.
Aber die Nuancen sind manchmal wirklich schwer festzustellen. Ja,
die haben sich ja auch sehr bemüht,
ein komplexes Bewertungsverfahren darum auszurichten, wie man das feststellt.
Es gibt ein ganz hübsches Buch über Software-Metriken,
die haben tatsächlich auch versucht,
ähnlich wie bei den Hotels,
so einen Punkt zu sehen
System zu verteilen. Also ihre Software kriegt aber
nur zwei Sterne von uns und das und das müssten sie
tun und dafür müssten sie natürlich von uns Leute kaufen,
um dann auf drei oder vier Sterne zu kommen.
Also sowas kann man natürlich alles machen. Und die Leute fragen einen
das natürlich auch. Ich will nur euer Augenmerk darauf richten,
dass wir haben ein Ziel, das können wir gar nicht messen.
Dann haben wir Faktoren, können wir auch noch nicht messen.
Dann haben wir Teilmerkmale und dann können wir langsam anfangen,
uns zu überlegen, dass zu so einem Teilmerkmal vielleicht die
und die Maße eine ganz gute Aussage wären.
Aber das ist immer nur argumentativ zusammenzubringen.
Es gibt hier keine direkte Abbildung. Ich habe euch mal
ein Beispiel mitgebracht
Wir stellen uns mal vor, wir wollen Wartbarkeit,
den Faktor Wartbarkeit irgendwie messen. Dann würde man sagen,
okay, von den Kriterien wähle ich jetzt mal das eine aus, Änderbarkeit.
Und sage mal, Änderungen sollen nur lokale Auswirkungen haben.
Ich sage, man kann Software besser ändern,
wenn man hohe Kollision und niedrige Kopplung hat.
Und wenn die Software Lokalität hat, also wenn ich Schnittstellen
habe und das Innere von Klassen oder von Subsystemen verborgen ist,
wir haben ja eben schon so über Schnittstellen gesprochen.
Und wenn ich keine Zyklen im System habe,
also wenn die Benutzung hierarchisch ist im System,
dann kann ich mir eine ganze Menge von Metriken vorstellen,
um das zu überprüfen. Also ich kann messen in Softwaresystemen,
wie stark die Korrision und die Kopplung ist auf verschiedenen Stufen.
Ich kann zum Beispiel messen, oh, jetzt habe ich geklickt, da.
Nee, da, ein zurück. Ich kann messen,
wie viele Ex- und Importbeziehungen eine Klasse oder ein Subsystem hat.
Also ich kann mir die Anzahl angucken,
denn wenn ich etwas änderbar haben will und sage,
dass etwas gut änderbar ist,
wenn es eine schmale Schnittstelle nach außen hat,
dann will ich natürlich, dass die einzelnen Komponenten wenig Beziehungen zueinander haben.
Also viele Beziehungen nützen auch nicht
so viel
So, und ich kann mir auch die Anzahl und die Größe der Schnittstellen natürlich angucken.
Also habe ich es in meiner Software geschafft,
jetzt versuche ich mal wieder das mit der Tafel.
Mal sehen, ob das geht. Habe ich es in
meiner Software geschafft? Ach nee, hoch geht nicht.
Komponenten zu haben, die alle einzelne Aufgaben erledigen und die,
wo es schmale Schnittstellen zwischen gibt, vielleicht so,
ja, und hier ist noch einer,
den benutzt vielleicht nur der.
Oder habe ich sowas gebaut?
Ich mache mal dasselbe dahin
Wo jeder jeden kennen muss und zwar ganz viel.
Und dann musst du ja auch noch vielleicht den kennen und den, ja.
Also wie stark ist das System verkoppelt, was ich gebaut habe?
Habe ich gute einzelne Aufgaben schneiden können, die getrennt voneinander sind.
Habe ich das geschafft? Und wenn ich das geschafft habe,
dann könnte ich natürlich sowas machen auch,
also wenn ich eine gute Änderbarkeit hätte,
könnte ich sowas machen und sagen, diese Komponente,
hier gebe ich dem und dem Entwickler,
der arbeitet da dran und ist total entkoppelt von dem anderen
oder nur über eine ganz schmale Schnittstelle mit dem verbunden.
Das ist also
gut änderbar
Ja, und dann könnte ich zum Beispiel überlegen,
dass ich an dieser Ecke hier weiter arbeite.
Oder an der anderen, ja. Was mir wichtig ist,
ist, dass ihr mitnehmt, es ist nicht so einfach,
Maße für irgendwelche Qualitätskriterien zu finden, die sich irgendjemand ausgedacht hat.
Das ist kein einfacher Prozess und da muss man
sehr viel argumentieren, dass das wirklich hinhaut. So,
jetzt gibt es zu Softwaremaßen eine ganze Menge an Theorie,
einen ganz kleinen Ausschnitt davon möchte ich euch zeigen,
damit ihr das schon mal vor Augen habt,
wenn ihr irgendwann in euren Firmen tatsächlich ans Messen kommt
Das erste ist einfach, man unterscheidet zwischen direkten und indirekten Maßen.
Direkte Maße sind solche Maße, die man einfach unmittelbar messen kann.
Zum Beispiel, ich kann die Anzahl an Zeilen Code messen.
Ich kann das einfach zählen. Es ist einfach was aufgezähltes. Ja,
ich kann die Gesamtanzahl der Fehler, kann ich einfach zählen.
Und ein indirektes Maß wäre zum Beispiel die Fehlerdichte. Ja,
ich will also rausfinden, wie die Fehlerdichte in meiner Software
ist und teile die Gesamtanzahl der Fehler durch die Anzahlen der Zeilen Code.
Je stabiler ein Softwaresystem ist, ist dann sozusagen die Aussage,
desto geringer ist die Fehlerdichte
Das ist aber natürlich auch eine lustige Idee,
weil man weiß ja gar nicht,
wie viele Fehler man noch nicht gefunden hat.
Also das ist sozusagen die Fehlerdichte der gefundenen Fehler.
Und dann könnte man sich vornehmen, wir testen besser nicht
so viel, weil dann finden wir nicht so viele Fehler.
Und dann ist die Fehlerdichte, ja, okay.
Also ihr merkt schon, man kann sich also ganz schnell
ins Bein schießen mit diesen ganzen Maßen.
Man muss ja genau überlegen, was will ich hier eigentlich ausdrücken?
So. Also bei mir in dem Projekt,
da beschweren sich die Leute zum Beispiel im Moment,
dass die Anzahl der erfassten Fehler hochgeht.
Dann könnte man sich einfach überlegen,
man entwickelt jetzt schneller und dann kommen sie gar nicht hinterher
oder man lässt sie ganz viel mit der Software arbeiten.
Dann kommen sie nicht dahinterher, ihre Fehler zu erfassen und
dann singt die Anzahl der Fehler wieder.
Das ist doch
total praktisch
Es gibt ja den schönen Spruch, straue nur der Statistik,
die du selbst gefälscht hast. Also wenn ihr irgendwo irgendwelche Zahlen,
also es ist immer schön, natürlich seine Chefs mit solchen Zahlen zu versorgen,
aber wenn euch jemand die vorlegt,
dann solltet ihr echt genau hinschauen und die hinterfragen.
Vor allen Dingen, wenn ihr euch damit was sagen will,
nämlich, dass ihr schlechte Arbeit macht oder was auch immer.
Also über solche Zahlen kann man sich sehr viel streiten.
So, dann kann man die auch noch so unterscheiden.
Also man kann nach externen Produktmaßen,
kann man Metriken betrachten oder Maße betrachten.
Das sind also Sachen, die in der Regel
nur indirekt von außen sichtbar sind
Interne Produktmaße, das sind Sachen,
die man messen kann in der Software und in der Regel
berechnet sich so ein externes Produktmaß eben dann aus intern.
Andererseits gibt es Prozessmaße, also wie lange dauert irgendwas?
Ja, da geht es dann mehr um die Prozessqualität,
habe ich euch vorhin schon gesagt. Online gibt es natürlich auch noch Ressourcenmaße,
mit denen man sich auch total viel beschäftigen kann.
Also die Maße sind sozusagen überall. So,
und im Deutschen sagen die Leute oft Metrik dazu,
aber mathematisch ist eigentlich das, was wir da tun,
ein Maß, weil wir keine Längen oder sowas messen,
sondern etwas was Abstraktes, ja, messen.
So, und ein Maß ist,
ich zeige euch gleich noch ein Bild dazu,
aber es ist wichtig zu wissen, eine Abbildung, ja.
Also die Zuordnung eines Messwertes, aus einem bestimmten Bereich,
zu einem Objekt, ja. Wenn ich jetzt sage,
ich habe was, was 500.000 Lines auf Code groß ist,
dann ist das ja eine Zahl, ja,
die ich diesem gemessenen Stück Source-Code zuordne.
Ja, und ich will damit irgendeine bestimmte Eigenschaft von diesem Objekt darstellen.
Ich zeige euch das mal, ich gehe mal eine Folie weiter,
da habe ich nämlich das Bild,
was sich jetzt erst aufbauen muss hier.
Oh, komm,
klick.
Also ich habe, wenn ich zum Beispiel Temperatur messe,
dann habe ich das reale Messobjekt.
Also ich habe den Füllstand in diesem Glasbehälter von der Temperaturanzeige.
Und ich selbst als Mensch ordne denen die Zahl 28 zu,
also 28 Grad wären schön. Oder ich sage,
14 Grad, da ist es ein bisschen kälter.
Also ich mache diese Zuordnung von einer Zahl,
das ist die Abbildung zwischen, die das Maß herstellt.
Die anderen Sachen erzähle ich gleich,
ich gehe nochmal wieder zurück und ärgere mich über diese Animation
Gut, der Messwert muss aber nicht immer unbedingt eine Zahl sein.
Ja, ich weiß nicht, ob ihr schon sowas mal
gesehen habt, aber wir machen bei uns häufig Risikolisten.
Ja, und dann machen wir so, wenn das Risiko
schon fast beherrscht ist und nicht mehr so schlimm ist,
dann kriegt es ein Smiley davor, der lächelt.
Und wenn es ganz doof ist,
dann kriegt es so ein Smiley mit runtergezogenen Mundwiegenhänden.
Das ist im Endeffekt auch ein Wert, ja.
Also es gibt dann eben wahrscheinlich kein Problem, mittel und schlimm,
ne? Sowas, ja? Das sind auch Messwerte.
Oder wenn es zum Beispiel in Firmen so Quantifizierungen von Fehlern
gibt, ja, hochmittelschwer.
Das ist auch ein Messwert, ja
Die Gesamtheit der Messwerte, die man für ein Maß hat,
nennt man eine Skala. Und ich werde euch gleich noch
verschiedene Arten von Skalen zeigen. Es gibt nämlich Skalen,
mit denen man rechnen kann und welche,
mit denen man nicht rechnen kann, die,
mit denen man rechnen kann, sind quantitative Skalen und die,
mit denen man nicht rechnen kann, sind qualitative Skalen.
Ihr könnt euch vorstellen, dass man mit einer Bewertung von
Fehlern in Hochmittel und gering nicht rechnen kann.
Was soll man mit Worten rechnen? Aber wenn jemand dann auf die schlaue Idee käme,
da Zahlen für zu verwenden und zu sagen,
also hoch ist gleich fünf,
Mittel ist gleich drei und gering ist gleich eins
Dann könnte man auf die Idee kommen, damit anzufangen zu rechnen.
Obwohl das nicht erlaubt ist, weil das ist nur eine qualitative Skala. So,
und mit dieser Theorie im Hinterkopf wird es euch bestimmt leicht fallen zu verstehen,
dass es nicht einfach ist, ein Maß zu definieren.
Da gibt es eine ganze Reihe von Theorie dahinter,
wie man überhaupt definieren kann, dass ein Maß richtig ist,
so wie man es aufgeschrieben hat,
also von einem auf das andere abbildet.
Und es hängt natürlich auch beim Messen immer von Umgebungsfaktoren an ab, gerade in der Software.
Also was die statische Architektur angeht, das ist noch leicht.
Aber wenn ihr an Performance-Messungen denkt, ist es sehr schwierig,
immer die gleiche Situation auf dem Rechner herzustellen,
Dann springt irgendwie der, keine Ahnung,
irgendein weiteres Programm aus Windows an,
Windows macht irgendwas im Hintergrund und schon ist die Performance-Messung nicht genauso wie vorher.
Also Messen, man muss immer daran denken, dass man
sich Gedanken darüber machen muss, was für Umgebungsfaktoren habe ich hier.
Wenn ihr dran denkt, dass ihr irgendwie die Zeiten messen wollt,
die jemand für irgendwie Erledigung einer Aufgabe bei der agilen Softwareentwicklung braucht,
für einen Pask oder so.
Das ist unheimlich schwierig, das hinzukriegen, dass das immer wieder dasselbe bedeutet.
Und das ist aber wichtig bei einem Maß,
dass eine Messung mit einer anderen absolut vergleichbar ist
Deswegen braucht man geordnete Messverfahren, um das sicherzustellen. So,
jetzt wollen wir uns nochmal eben dieses Bild hier angucken. Also,
wir haben auf der einen Seite reale Objekte von Temperaturen,
ja, ganz heiß, kalt, keine Ahnung,
was das ist, hier noch kälter wahrscheinlich.
Und wir würden sowas sagen, wie das ist wärmer als das und das ist kälter als das.
Ja, das ist aber unser subjektives Gefühl von dem,
was wir in der Realität wahrnehmen. Ja,
und dann, das nennt man auch das empirische Relationssystem,
also es gibt eine Relation zwischen diesen Sachen und man könnte das auch nicht mit Worten hinschreiben,
sondern mit irgendwelchen Symbolen, ja, man könnte also hinschreiben,
Das ist, und das wärmer Umsetzen in ein Bild, so.
Und was wir dann als Menschen machen,
wir ordnen diesen realen Objekten Zahlen zu,
die nennt man auch formale Objekte, ja,
und sagen dann 28 Grad ist wärmer als 14 Grad und
8 Grad ist kälter als 14 Grad.
Aber damit können wir nicht rechnen, ja.
Wir können ja jetzt nun nicht sagen,
irgendwas wie 7 Grad ist halb so warm
wie 14 Grad
Hat das irgendeine Bedeutung? Nee, das entspricht, das ist
sozusagen bedeutungslos. So, das ist das sogenannte formale Relationssystem,
was man da auf der anderen Seite hat,
mit den Werten, die man ermittelt.
Und das Maß bildet, bildet das im Grunde ab.
Ja, das reale Objekt auf das formale Objekt.
Das ist das, was ein Maß tut.
Und ja. Ja, das ist immer die Frage,
wie man das betrachtet, aber das kann man so sagen.
Weil ich habe den jetzt eben schwupps von unten gelesen.
Ja, ihr könnt den gerne umdrehen und
nächstes Mal drehe ich den auch um
Kälter als ist andersrum. Genau. So. So,
und jetzt muss man immer gucken, dass das Maß und
die Relationssysteme, die man da hat, zueinander passen.
Und dann bekommt man eine Skala hier auf dieser Seite.
So, ich zeige euch jetzt die Arten von Skalen,
die es gibt. Es gibt auf der einen Seite
qualitative Skalen. Bei solchen Skalen kann man
nur mit Vergleichsoperatoren arbeiten
Da gibt es einmal die Nominalskala und die Original-Skala.
Mit der Nominalskala werden wir in den nächsten vier Wochen ganz viel zu tun haben,
weil wir werden uns mit den Trikotnummern von Fußballspielern beschäftigen,
die nächsten Monate.
Jedenfalls die von euch, die gerne Fußball gucken.
Die sind natürlich, das ist auch ein Maß, ja.
Also Ballack hat die Nummer so und so und jetzt hat
die jemand anders. Es ist eine Zuordnung, ja,
von Menschen auf Trikotnummern. Und man kann sowas sagen wie,
diese Nummer ist nicht dieselbe wie die andere, ja,
bei den Matrikelnummern ist das genauso.
Ihr habt jeder eine Matrikelnummer, ja, die ist euch zugeordnet.
Es gibt also in irgendeiner Form ein Maß,
um zu sagen,
Carola Lilienthal hat die Matrikelnummer
Ich kann das auch unterscheiden, denn meine Matrike-Nummer ist eine
andere als eure, aber ich kann nicht damit rechnen.
Also es gibt nur eine Unterscheidung in gleiche und ungleich.
Zum Beispiel, wenn ich sage,
mein Software-System ist in Java gebaut und ihr sagt,
meins ist in C plus plus gebaut,
dann ist das auch schon ein Maß auf einer Nominalskala.
Aber ich kann auch nicht damit rechnen.
Ich kann die Dinger nur unterscheiden. Ja, so.
Die nächste Art von Skala ist die Originalskala,
über die haben wir eben auch schon gesprochen.
Und da sieht man auch,
dass die Lehrer das mit den Maßen nicht so wirklich verstanden haben,
weil die rechnen mit den Schulnoten
immer irgendwelche Durchschnitte aus
Das geht eigentlich nicht. Das ist eine Originalskala,
wo man einen Größenvergleich machen kann und man kann einen medialen,
also den Mittelpunkt in der Menge der vorhandenen Werte berechnen,
aber man kann keinen Durchschnitt berechnen eigentlich.
Windstärken sind auch sowas, weil man könnte ja auch,
man muss ja die Schulnoten nicht von 1 bis 6 machen,
sondern ihr habt es selber erlebt,
man kann auch 1 bis 15 machen oder irgendwas anderes.
Könnte man mit den Windstärken auch machen.
Man könnte das einfach umdefinieren auf andere Werte.
Das sind also keine wirklichen Zahlen zum Rechnen.
Genauso ist es mit Fehlern und Gefahrstufen.
So,
das sind qualitative Skalen
Und eins der meiner beliebtesten Spiele ist,
wenn ich Leute mit sowas rechnen sehe, zu sagen,
das geht aber nicht.
Damit darf man jetzt nicht rechnen. Das ist nichts zum Rechnen
. Und auf der anderen Seite gibt es quantitative Skalen,
mit denen kann man rechnen. Nein, da gibt es
drei verschiedene, die sogenannte Intervall- oder Differenz-Skala.
Das sind Mess, das sind Zahlenwerte, die keinen natürlichen Nullpunkt haben.
Also zum Beispiel der Projekt Fortschritt, gemessen an Aufwandspunkten,
was bedeutet Null eigentlich? Oder Temperatur in Celsius,
denn die Null ist unsere Null in der Temperatur-Skala,
da gibt es auch Minuswerte.
Also die ist sozusagen nicht die Null von,
hier ist der Anfang,
hier ist der Ursprung
Da kann man Differenzbildung machen, aber es ist ein arathmetisches Mittel und sowas berechnen.
Dann gibt es Verhältnisskalen, da gibt es einen Nullpunkt,
also zum Beispiel bei der Größe eines Programmes kann ich sagen,
so hier ist null, hier fange ich an,
das ist null byte oder es gibt auch eine Temperaturskala,
die eine Verhältnisskala ist.
Das sind die Temperaturen in Kelvin, die es auch gibt.
Da ist null tatsächlich der absolute Anfangspunkt, es gibt keinen Minus.
Bei denen kann man richtig gut mitrechnen,
also Quotienten bilden und Mittelwerte und Varianzen und so weiter oder Preise und Längen,
also mit denen wir auch viel rechnen eigentlich in unserer Welt,
ja,
sind wir ganz gut auf der guten Seite normalerweise,
wenn wir rechnen
So, und dann gibt's noch die Absolute Skala,
die aber nichts weiter Besonderes hat. Das ist nur ein Spezialfall
der Verhältnissskala. Da kann man die Anzahl von Programmzeilen rechnen.
Nur zur Entwarnung und weil ihr so brav zugehört habt,
nach den Dingern werde ich nicht fragen in der Klausur.
Also da braucht ihr euch keine Sorgen zu machen nach diesen Skalen.
Aber trotzdem solltet ihr sie für euer Leben nicht vergessen.
Zumindest den Satz, dass man bei solchen Messungen
immer genau aufpassen soll, was einem da blüht.
So. Und jetzt werden wir das nicht schaffen,
deswegen gehe ich da mal raus und mache mal wieder einen
meiner beliebten Abkürzungstricks und gehe nach hier
Weil das ist einfach zu viel für uns heute bei den Temperaturen.
Und beglücke euch mit dem Schluss. Also,
was ist wichtig, was möchte ich,
dass ihr mitnehmt für die nächsten Wochen und Monate.
Ihr habt ein bisschen was gesehen, so einen ganz kleinen Geschmack davon gewonnen,
dass man bei Architekturanalyse den Plan und die Realität miteinander vergleichen kann.
Man kann also den Plan,
den die Leute sich für ihr Softwaresystem gemacht haben,
auf die Ist-Architektur übertragen und kann bestimmte Arten von Verletzungen finden,
die wir eben gesehen haben,
auf die ich euch ganz besonders hingewiesen habe,
dass die
ganz wichtig sind zu wissen
So, und dann habe ich euch was gezeigt zu Softwaremessungen,
ja, also dass man verschiedene Sachen messen kann und dass man sich immer im Klaren sein muss,
was will man hier eigentlich,
was ist das Ziel der Messung, die man da macht,
was ist vielleicht auch das Ziel von dem anderen,
der da gemessen hat, ja,
das steht hier besonders bei wichtigen Botschaften übers Messen, ja,
man muss unbedingt sorgen, ungemein sorgsam mit den Grundbegriffen umgehen,
also worüber rede ich hier gerade,
was für eine Skala habe ich hier gerade,
wie definiere ich dieses Maß, das ist eine ganz eigene Disziplin,
diese ganze Messtheorie und wenn ihr das bei euch in euren Unternehmen verwendet,
dann wird das immer nur, ja, da müsst ihr zusehen,
dass ihr wenigstens an eurem Unternehmen ein einheitliche Art von Messungen habt.
Ja, das wird sich von Unternehmen zu Unternehmen sowieso wieder unterscheiden. Gut,
das war der Ritt durch die Maße und das ist jetzt
der fertige Plan auf meiner Seite für das Ende des Semesters.
Ich übernehme keine Verantwortung für Axels Seite, aber für meine Seite übernehme ich die Verantwortung.
Wir haben uns heute um Qualitätssicherung gekümmert. Nächste Woche wird
Hartmut Obendorf hier sein und euch was zu Usability erzählen.
Das ist ein Mitarbeiter von mir aus der C1 wie PS aus der Firma,
der sich in seiner Doktorarbeit auch mit dem Thema beschäftigt hat Und ich hoffe,
dass ihr hier zahlreich sitzt und ihm interessiert, lauscht.
Dann bin ich wieder da und, oh,
falsche Richtung und werde euch was zur Integration von Softwaresystemen erzählen.
Das heißt, ich werde mit euch einen Blick über,
ich baue ein Softwaresystem zu, ich verbinde mehrere Softwaresysteme miteinander und wie macht man das, werfen?
Ein unglaublich wichtiges Thema in meiner Wahrnehmung. Dann freue ich mich sehr,
dass ich euch ankündigen kann,
dass in der Woche danach ich einen Kollegen überredet habe,
uns ein bisschen was über SAP zu erzählen,
weil das euch in den Firmen,
in denen ihr nachher arbeiten werdet, immer begegnen wird
Und ich habe vor diesem Teil lange Zeit sozusagen quasi nicht gewusst,
was ist das eigentlich, ja, was ist SAP, wie geht das?
Und wenn einem einer mal ein bisschen was erzählt, ist das gut.
Und hier zum Schluss habe ich noch so ein Thema reingequetscht,
was mir auch sehr wichtig ist. Ich möchte euch gerne noch was dazu beibringen,
was eigentlich der Unterschied ist zwischen so einem System,
was ihr jetzt baut in Swing oder so, ja,
dieses Kinokartensystem und dann der Webclient,
weil heute immer mehr und mehr Software ist natürlich Software,
die im Internet läuft und ihr müsst wissen,
was das bedeutet, so grob,
wie das geht.
Das möchte ich euch zum Schluss noch beibringen,
da wird aber auch noch Zeit sein,
über die Klausur zu sprechen und uns darüber
ein bisschen zu unterhalten
Also noch ein paar spannende Themen für den Rest des Semesters.
Und ich hoffe, ich habe jetzt genug Werbung gemacht.
Ich wünsche euch einen schönen Tag, schönes Wochenende,
ganz viel Sonne, Fußball, was auch immer.
Macht's gut