So, nun kommt der letzte Abschnitt der Vorlesung.
Das Kapitel 7 ist sehr kurz, denn das Kapitel 7 beschäftigt sich,
bildet nur den Rahmen für Vorstellung, konkreter Werkzeuge im Seminar.
Wir haben hier in dieser Vorlesung nur ganz allgemeine Diskussionen,
wozu die Werkzeuge eingesetzt werden können. Und ich möchte Sie auf eine Seminararbeit hinweisen,
die wir hier auch hochgeladen haben, die sehr weiter sehr schöne Informationen dazu noch aufbereitet.
Also hier sehen Sie in der Gliederung, worum es geht. Und die Fragen sagen auch so ein bisschen,
Was wir holen, die uns nur hier beschäftigen, nämlich erstmal die Ziele,
was in den Prioritäten, wo können wir überhaupt automatisieren,
das ist so ein bisschen mein Beitrag zur Diskussion,
den wir häufig in Firmen haben, dass die Chefs,
sage ich mal, die Manager,
denen wird alles Mögliche versprochen auf irgendwelchen Messen,
super automatische Tools auf Knopfdruck, machen die alles,
dass wir überlegen, was sind überhaupt für Tätigkeiten mit Adomobilisierbar.
Da spielt natürlich ein bisschen unsere Erfahrungen aus der Forschung mit rein,
das sollte für den Meisterstühlinggang ja auch so möglich sein.
Und einfach ein Nutzenverhältnis, also wo können wir was erwarten,
was helfen uns die Werkzeuge möglich
Das ist, lassen wir uns hier gleich beginnen mit einer
kleinen Tabelle für die verschiedenen Tätigkeiten, die wir hier haben.
Wir verstanden also mit den Zielen des Werkzeugeinsatzes. Das war auch das,
was als Folie 1, als Frage 1 formuliert war.
Am liebsten hätte ich das mit Ihnen interaktiv zusammen gemacht.
Das geht nun in dieser Form der Aufzeichnung nicht.
Deswegen kommen die Inhalte leider nur von mir.
Sie können ja bitter mal überlegen parallel,
was Sie denn hier, wie Sie das nennen würden.
Also es geht uns um Ziele des Werkzeugeinsatzes
Und das sind zunächst erst mal drei oder zwei ganz große Punkte.
Das eine ist Effizienzgewinn. Effizienz als Verhältnis zwischen
aufgewindeten Aufwand und erzielten Nutzen, im Gegensatz zu Effektivität,
wo es um das Ergebnis überhaupt geht. Also Effizienz,
dieses Aufwand-Nutzen-Verhältnis, das wäre vor allen Dingen bezüglich der Zeit,
wäre das eine Beschleunigung der Arbeiten, also kürzere Zeit oder auch,
dass wir insgesamt weniger zu tun haben,
weil die Maschine was übernimmt,
Wobei der Aufwand immer der Zeitaufwand des Entwicklers hier bei so einer Sache ist.
Der zweite wichtige Punkt uns holens Werkzeuge, helfen können,
ist die Fehlervermeidung. Menschen machen Fehler, bekanntermaßen.
Sie kennen von mir diese Zahl, drei Prozent,
die ich auch mal irgendwo geführt, gehört, gefunden habe.
Ich kann sie nicht mehr zitieren. Also man sagt ja,
drei Prozent Fehler machen die Menschen, wenn man sich ganz viel Mühe gibt,
kann man das bis auf ein Prozent senken.
Das bedeutet aber,
bei 10.000 Lines of Code haben wir schon mal 300 Fehler
oder bestenfalls 100 und das ist schon viel und 10.000 Lines
of Code ist nicht viel
Ja, also deswegen, Aufwandsfehlervermeidung, Maschinen können Sachen sehr systematisch machen.
Vergessen nichts, haben kein begrenztes Kurzzeitgedächtnis, sondern scheinbar unbegrenztes Speicher.
Also da geht es sehr viel besser. Und deswegen können
die das überall leisten. Wir kommen ja als nächsten Punkt gleich,
wo ich nicht Kultomatisierung wirklich, also Fehlervermeidung wäre jetzt hier,
wenn wir Probleme löblich vollständig lösen.
Vollständige Problemlösung, ohne dass man was vergisst,
so wann die Maschine es halt finden kann,
wenn die Regeln nach gegen die Maschine arbeitet,
nachdem Algorithmus arbeitet, gut sind, wäre das vollständig möglich.
Das nächste ist, dass wir nachverfolgbarkeit erhalten. Natürlich können Sie es so machen,
dass Sie dem Entwickler vorschreiben, bitte,
wenn du etwas tust und das hängt von irgendeiner Antwortung ab oder ein Test,
hängt damit zusammen, bitte schreib es in die Matrix und schreib dorthin,
wer hängt mit wem zusammen.
Aber die Gefahr ist, es klingelt oder die Mittagspause oder
was auch immer, der Entwickler macht, das vergisst das.
Ja, das Tool würde es nicht vergessen. So,
das Nächste, was ich hier nennen möchte,
ist Verbesserung von Eindeutigkeit, weil wir es formen,
nun Formalisierungsgrad haben
Also, bitteschön, Sie können mich jetzt schelten,
warum kann man Eindeutigkeit verbessern? Entweder etwas ist eindeutig oder nicht,
ja, wieso Verbesserung, das ging nach einem Kontinuum,
ich meine hier, dass man von einer natürlichen Sprache,
von einer gemischten Notationen halb formal,
wie zum Beispiel in Nomelles,
schrittweise mehr formalisiert
Ist mir möglich und auch eine Voraussetzung dafür,
dass wir Tools anwenden. Und das ist dann Steigerung des
Formatisierungsgrads wäre eigentlich der ganz korrekte Eindruck.
Und natürlich Tools helfen uns dabei, Komplexität zu verringern.
Das kann durch eingeschränkte Darstellungen sein
Das kann dadurch sein, dass wir Abstraktionen nutzen,
die wir ein- und ausklappen können,
hat auch wieder was mit Darstellung zu tun.
Man hat damit zu tun, dass wir Dinge auslagern in einem Generator.
Dass wir dadurch nicht so viele Details, so viel Länge zu haben,
dafür steigt beim Generator manchmal die Komplexität der Darstellung.
Also das sind, das sind Dinge, wo ich,
wo ich das nennen würde,
das sind die beiden Hauptpunkte und als weiteres möchte ich noch
nennen Unterstützung von Arbeitsteilung
Für Entkupplung und Parallelisierung. Euer Lehre kommt hierhin und hier in Licht.
Entkupplung und Parallelisierung und dann natürlich haben wir verbesserte Ja,
verbesserte Kontrollmöglichkeiten. Es ist ein Punkt auf der vorderen Ebene
. Und als letztes Punkt, dass man am Ende
mehr Komplexität beherrschen kann.
Beherrschung komplexere Aufgaben
So, und wenn wir jetzt sagen, die Priorität steigt,
dann würde das so ein, ups, das habe ich mir schlecht geraten.
Machen wir nochmal. Das würde so ein Pfeil sein.
Also, die Priorität, die höchste Priorität,
die man dem Werkzeugeinsatz zuweist, ist dann alles,
was man mit Effizienzgewinn zu tun hat und Fehlervermeidung.
Die anderen Punkte hier unten, Beherrschung komplexerer Aufgaben,
das sind Punkte, die meistens im Hintergrund stehen.
Es gibt natürlich auch Projekte, wo die Kontrolle allein Und
zwar im Vordergrund steht, das wäre auch noch ein Punkt.
So wie er zur Frage 1,
ich gehe noch mal zurück, um die kurz zu zeigen.
Ja, Ziele ins Werkzeugeinsatz ist in der Priorisierung.
Als nächstes möchte ich kurz mit ihm drüber sprechen,
welche Aufgaben sind denn überhaupt automatisierbar?
Ich habe hier gleich in der Fragestellung ein paar angegeben,
die übernehmen wir gleich mal und überlegen, was davon priorisierbar ist.
Dazu brauchen wir, machen wir mal eine Tabelle,
wo wir das gegenüberstellen, dass wir das besser auf einen Blick hat.
Und diese Tabelle hat zunächst erst mal längst
die Tätigkeit als Spalte
Und dann, was ist daran automatisierbar? Dann, was
ist nicht automatisierbar und... So, und diese Tätigkeit,
die wir hier hatten, war also Die Erstellung bzw. Forward-Engineering,
dann gab es, das hat mir in der Aufgabenstellung, Restrukturierung.
Vielleicht lasse ich mal ein bisschen Platz, wir haben insgesamt
irgendwie sieben Sachen, glaube ich, nein, sechs.
Mal schauen, die nebenbei. Sechs Stück,
die verteilen wir ein bisschen gleichmäßig über das Blatt
Ich finde das ja hier bei mir einfach schieben,
sodass wir die gleichmäßig haben.
Dann hatten wir Erkennung, Revue Engineering,
Dokumentation,
Test und Integration
So, soweit erstmal die Haupttätigkeit, die wir untersuchen wollen
oder diskutieren wollen. Und jetzt geht es darum,
das hätte ich sehr gern mit Ihnen interaktiv gemacht.
Leider sehen Sie das erst, nachdem ich,
dass mein Computer schon wieder ausgeschaltet habe und das konvertiert habe.
Also kommen jetzt mal die Sachen von mir, was ist denn hier automatisierbar?
Beim Erstellen tatsächlich ist es automatisierbar, manche Teile des Codes
können generiert werden. Also vor allen Dingen Rahmens,
Kalette, die Sachen mit Namen, Kopfzeilen, so etwas,
auch manchmal Bedingungen, je nachdem,
was man vorher formal beschrieben hat
Keine Dekodierung sind hier automatisierbar. Und was nicht automatisierbar ist,
die Linie, ist zum Beispiel die Erstellung des Entwurfs.
Was nicht erstellbar ist,
ist wirklich Entscheidungen für zum Beispiel für eine Plattform oder sowas
Wie gehe ich an ein Problem heran? Bei der Architekt sagt er
den Begriff Taktiken dazu, sie können auch Designpatterns hier gerne mit reinschreiben.
Das wären also Sachen, die ich nicht machen kann.
Am Ende meine ganz persönliche Meinung ist,
für das Forward Engineering lohnt sich Automatisierung nur selten,
nämlich nur, wenn ich einen hohen Anteil an schematischen Code habe,
wie zum Beispiel beim Zugriff auf relationale Datenbanken oder beim Portieren
für grafische Anwendungen oder beim Umsetzen von einer Imitation in eine andere.
Aber alles dafür, für all diese Sachen gibt es
schon Werkzeug
Für das Recht strukturieren, da würde ich mal sagen,
gut automatisierbar sind solche Sachen wie Clone Detection.
Wir haben das ja anhand des abfragten Syntagsbaums,
haben wir das ja in der Vorlesung behandelt.
Dann statische und Strukturanalysen. Darum ist dem Quergut
Natürlich kann man das alles auch von Hand machen,
aber das kann ein Tool ganz gut.
Diese statische Analyse. Was ein Tool dabei nicht kann,
ist, dass er aus dem Namen den Sinn ermittelt.
Also herstellen von, ich nenne es mal Finden von Bezügen,
Finden von Bezügen zum Fachlichen,
zur Fachlichkeit
Also das mentale Modell, wie sieht die Architektur aus,
wie die schäge Struktur aus, was sind Verantwortlichkeiten von Komponenten,
das kann typischerweise ein Tool nicht finden.
Genauso, was sind Implementierungsdetails, was gehört zur Schnittstelle,
was wir im Vorraketenabschnitt hatten, Testsee, Interface, Not the Implementation,
die sind solche Entscheidungen, das kann ein Tool typischerweise nicht.
Dann hatten wir hier für die Dokumentation, ach so,
Erkennung, genau, das finden wir hier mit tatsächlich dass eine zunächsten,
dann habe ich doch hier tatsächlich was falsch gemacht,
meine Notizen waren nicht außergekräftig genügt.
Ich kann das oder so mal dieses hier einfach mal
ein Stückchen tiefer schieben. Ja, da würde ich,
wenn wir jetzt den Platz haben,
noch bei Restrukturierung gerne noch hinzufügen,
dass man die Steuer fürs Korrektur,
wie sowas wie mit diesen Go-To-Ersetzen oder sowas
Das war das durchaus automatisch machen kann. Wir hatten in dem Abschnitt
ja darüber gesprochen, dass es da ein paar Nachteile gibt.
Zum Beispiel, dass typischerweise die Namen nicht mehr so treffen,
dass Kommentare da nicht mehr weiter dabei bleiben.
Das wäre noch ein weiterer Punkt. Und genau,
was habe ich hier noch in meinen Notizen? Genau,
das würde eigentlich das Gleiche, würde hier nochmal zutreffen.
Also auch hier diese Finden von Bezügen,
das kann man
ganz schlecht machen
So, Dokumentation ist auch noch etwas, was ungeliebte Tätigkeit,
sehr aufwendige Tätigkeit, doch erfolgskritisch für, das heißt,
ja, was kann ein Tool hier leisten?
Wir können erst mal sagen, was kann ein Tool nicht leisten?
Verständliche Inhalte so darstellen, dass der Gegenüber sie wirklich versteht.
Das können manche Menschen ja schon nicht, weil sie sich
nicht vorstellen können, was andere als nicht wissen.
Das heißt, ich fange mal hier drüben an
Erstellung von Inhalten können wir am Tool nicht erwarten,
dass es das kann, um Formulieren von Wissen.
Auch wenn wir sagen, KI und sonst die Wissensgesellschaft,
das geht mechanisch, das ist zur Statistik,
Begriffe, die schon irgendwo standen.
Ja, nur anders dargestellt. Und mit einem relativ hohen
Fehler gerade. Warte. Also was das Tool aber trotzdem
kann, wäre, diese Informationen zusammenbauen, aufbereiten.
Das nennen wir, ich würde mal das so formulieren,
Integration von vorhandenen Inhalten.
Das sollte vielleicht besser ein O sein hier
Von vorhandenen Inhalten, dann vielleicht noch Konvertierung von Informatik,
von Darstellungen. Und Aktualisierung würde ich da noch nennen.
So, dann, ja genau, soweit.
Dazu Test, nächster Punkt. Auch etwas sehr Aufwendiges.
Sie haben immer von mir gehört, dreimal so aufwendig wie Implementierung.
Also das ist, da möchten wir auch gerne Unterstützung dabei haben.
Und natürlich, was tun zu können,
ist Testdurchführung,
Was das Tool nicht kann, ist gute Testfälle entwickeln.
Und als letztes Punkt Integration,
das wirkliche Zusammenfügen im Sinne von Make oder sowas,
das kann das Tool natürlich auch wirklich.
Und was das Tool nicht kann typischerweise ist,
entscheiden ist eine Konfiguration korrekt.
Konfiguration im Sinne von,
die richtigen Teile zusammenfügen
Überkorrekte Konfiguration. Soweit, das wäre auch meine Antwort,
gleich auf die Frage 2, wo wir sagen,
was für Tätigkeiten sind denn das, wie wir überhaupt automatisieren können?
Und damit lassen Sie uns noch zu dem,
also hier diese Tätigkeiten und Aufwandnutzenverhältnis, das sehen wir aus der gleichen Tabelle,
nämlich das sind all die Tätigkeiten, die wir,
wo wir gutes Verhältnis von Vorarbeiten, die wir tun müssen,
recht gut ist.
Ich mache das mal jetzt mit Grün. Ja, also,
wo wir relativ ganz klar Gutes auf ein Nutzenverhältnis haben, ist das hier.
Ja, also, wir haben da sehr viel mehr Sachen für das Tool jetzt wirklich unterstützen kann. Genauso hier bei Testdurchführung,
bei der Aktualisierung von Dokumentationen, ja, das hilft uns ein bisschen,
aber das Wesentliche ist doch schon das Schreiben der Inhalte,
bei den Architekturanalysen, da helfen, helfen uns Tools,
sehr gut, bei dem Restrukturieren nur, was das Detection betrifft,
wirklich die Bezüge für das Erkennen von Fachlichkeit und bei der Kodierung,
da würde ich eher sagen, beim Vorward Engineering,
da ist es eher wenig beschränkt auf die Teile,
wo wir wirklich ganz viel formalisierten,
schematischen Pult haben.
Soweit dazu. Ich möchte Ihnen zwei Tools nennen,
die uns als Beispiele, die wir uns hier helfen,
eins nenne ich mal hier, als ein Tool Structure 101,
als Vertreter der Architektur-Analyse-Tools.
Es ist bei Structure 11 Handel sich so um ein kommerzielles Werkzeug,
das heißt, Sie brauchen eine Lizenz,
sie kaufen müssen und die wesentlichen Leistungen sind die hier dargestellten.
Also eine Quellcode-Analyse, das System, das Tool kann daraus
ein Abhängigkeitsmodell erstellen, also Aufrufbeziehungen, Paketbeziehungen, Sichtbarkeiten.
Sie haben die Möglichkeit, eine Sollarchitektur zu beschreiben.
Das ist nicht ein grafisches UML-Modell, sondern einfach nur
ein Ausdruck dessen, was sie da haben wollen.
Und die Ist-Architektur würde die als Abhängigkeitsmodell oder die Ist-Architektur
verwendet umgekehrt. Und daraus hin kann das Tool Verletzungen,
erstmal Darstellungen ermitteln und dann Verletzungen ermitteln
So, und zusätzlich hat man noch die Möglichkeit auch,
ganz viel aufgrund der Coldcode-Analyse, Metriken zu prüfen, Metriken anzuwenden.
Aber sie müssen natürlich dafür selbst die Schwellwerte zu formulieren.
Was ist gut? Bis zu welcher Fänze toleriere ich etwas? Was wir,
was für uns eine wichtige Funktion ist, dass wir,
was nicht zusätzlich ist, deswegen nicht dieses Tool als wertvoll betrachte,
man kann schon mal relativ leicht simulieren, was würde denn überall,
wo würde es denn überall Aufwand erfordern,
Anpassungen zu machen, wo passt etwas nicht,
wenn ich ein gewisses Refectoring,
eine gewisse Strukturänderung vornehme
Es gibt die Möglichkeit, die komplexen Informationen,
die ich aus der Abhängigkeitsanalyse zusammen habe, zu strukturieren,
um anzupassen an das, was ich jeweils machen möchte.
Und wir haben die Möglichkeit, auf das wir das deutsche,
das wird so ein Abhängigkeitsmodell ablegen können für verschiedene Versionen,
das gegenüberzustellen und damit eine Zeit, zeitliche Entwicklung verfolgen zu können,
was uns auch Informationen darüber gibt, ach,
was könnte denn da passiert sein?
Hier ist ein kleines Bildchen, ein Screenshot,
den man so finden kann, der zeigt,
wo wir Abhängigkeiten haben, und wo wir sehen,
wo Strukturen schlecht sind.
Also Sie sehen hier schon die Farbskala hier links.
Was ist gut strukturiert, was ist schlecht strukturiert?
Und wir haben dann doch ein sehr rotes Bild.
Also da stimmt einiges Licht. Ja, und ich kann
das irgendwie darstellen. Ich habe hier verschiedene Sichten,
wie ich dann die grafische Bünzerschnichte so darstellen kann,
weil das die erschließen.
Also erschließen dieser komplexen Informationen von großen Systemen.
Das ist der eigentliche Knackpunkt. Und bei kleinen Systemen
schauen wir das Dunkelherd gut an und Sie behalten das vielleicht
sogar an Prozentgedächtnis
Und was wir damit machen können, ist jetzt eine wichtige Tätigkeit,
dass wir Architektur, Verletzungen machen können. Diese Architektur,
Verletzungen können wir so machen, dass wir zunächst in Sollarchitektur beschreiben,
das hatte ich eben schon gesagt, das machen wir,
indem wir zum Beispiel Module definieren,
indem wir Schichten definieren oder gar direkt Regeln definieren.
Regeln, wie denn manches gemacht werden soll. Die Istarchitektur kommt
aus der Quellcode-Analyse, das war eben schon kurz genannt,
wir können uns eine grafische Anzeige machen lassen,
wie wir es eben in Beispielen gesehen haben.
Und dann macht man typischerweise,
weil es einfach zu viel wird oder alles rot ist oder so,
dass man erst mal überlegt, was brauche ich denn?
Man schränkt die Regeln etwas zurück. Zum Beispiel ist es sehr ratsam,
dass man nur aktuelle Verletzungen, nur neue Verletzungen zeigt,
damit man nicht am Ende finden,
wenn sie da 100.000 Fehlermeldungen haben, führt das nur dazu,
dass das Tool wieder abgeschüttet wird.
Sie müssen das reduzieren, sagen wir mal,
auf 10 oder 15, die zum Beispiel nur das Zeichen,
was gerade jemand gemacht hat.
Alles bisherige wird als akzeptiert gegolten, gilt,
man prüft prüftlich in die letzte Version und gegen die Sonnenarchitekturverletzungen darin und da
könne man das zum Beispiel nutzen,
um aktuelle Arbeiten zu überwachen.
Das ist eigentlich
der Punkt
Die nächsten, der nächste Punkt hier,
sie können mit verschiedenen Sollarchitekturen, ach hier fehlt direkt was.
Das wusste man, ich muss hier von hinten rein schreiben,
dass sie hier eine Simulation durchführen. Da sie also,
die sagen, das und das möchte ich gern verwenden,
dann schauen Sie mal, wo es überall Vorletzungen angezeigt kriegt.
Das wäre diese Simulation, die wir eben auf
der Vorgehenden Folie schon auch schon haben
Was eine weitere Möglichkeit ist,
mit der Menge der Flut an Informationen zurechtzukommen und die Menge der Regeln auf etwas zu beschränken,
was man tatsächlich innerhalb der nächsten paar Wochen schaffen kann,
indem man die Architektur Ops,
das soll kein Strich richtig werden, sondern nur ein Klinge,
indem man die Architektur grober gestaltet.
Also hier der dritte, der dritte Anstrich,
damit lassen Sie mehr Regeln mehr und mehr in die Entscheidung des Entwicklers.
Sie sagen, okay, das sind zwei Regeln,
die ich auch formuliert habe als Architekt,
was ich gerne so sehen würde,
aber die Entwickler dürfen auch was anderes machen,
sie wird tolerieren, also Abweichungen.
Das wäre das,
was wir in der Praxis dann an den Entwicklern delegieren
Oder dass wir als drittes, dass wir die kleinen Komponenten ausblenden.
Nur die großen, richtig größere Ebene zunächst betrachten und damit
Sachen erst mal sagen, so wie die Information Heidi-mäßig,
also was da inton ist, das toleriere ich erst mal.
Ich möchte erst mal eine große Ebene klar haben und dann räume ich da intrin auf.
Das hilft auch, dass man überhaupt erst mal weitergeht.
Wenn Sie gleich mit der vollen Ladung vorangehen,
also ich habe noch von keinem Projekt gehört,
wo das erfolgreich war, typischerweise wird das entweder,
man kriegt vom Chef da eine Weise und sagt,
ihr macht jetzt aber wieder was anderes,
Geld verdienen ist jetzt wieder angesagt oder die Entwickler sind so genervt.
Jedenfalls wird das Tool dann abgeschaltet,
wenn das nicht schafft
Menge der Fehlermeldung auf einfachen Sportes war es, zukunftstoil.
So, zu reduzieren. Und jetzt, der letzte Punkt,
den ich einfach noch nennen möchte, man kann dieses,
das erlauben diese Tools oder gerade das hier,
man kann die Verletzungserkennung tatsächlich auch als Sperrer benutzen,
damit kein Bild gemacht wird.
Zum Beispiel, wenn zu viele Verletzungen sind, bilden die statt.
Das könnt ihr durch eine Maven-Videgration gemacht werden.
Das Tool, ich hatte erwähnt, es kann Metriken.
Ich habe hier zwei Metriken genannt. Fett ist eine Metrik,
die kannten in Abhängigkeitsgrafen bewertet, ja, und sie können jetzt sagen,
ob sie die Ebene der Packages wollen, die Clevit der Katsche,
Klassen oder Methoden und Väter von Klassen und von Objekten,
ja, und auf der Ebene von Methoden, es ist das Fett,
genau, die ziplomatische Komplexität, also die Menge der Ausführungsvater.
Ein weiteres Beispiel für eine Metrik, die ich vorhin,
es gibt also ganz viele Metriken, die Sie haben möchten,
aber wir wollen immer Zyklen vermeiden, ja,
weil Zyplen für Tests ganz schwierig sind,
für Updates ganz schwierig sind und für das für Migration und Lösung.
Ja, also da können wir zum Beispiel so typische Abhängigkeiten
auf Package-Ebene machen, da gefährliche Metrik,
Design Tangles
Ja, kleines Beispiel, was ich mit Regeln meine.
Also sie stellen sich so etwas auf, wie eine Sollarchitektur,
hier eine ganz simple. Und dann sagen sie,
okay, in der Sollarchitektur ist jetzt hier das erlaubt,
was hier als rote Pfeile drinsteht.
Und alles andere ist nicht erlaubt. Ja,
das habe ich hier, es steht auf die Quelle,
da gibt es einen mit einem Artikel von Herzbischale irgendwie dazu,
den finden sie mit Suchmaschinen.
Okay, soweit schon zu One-on-One. Mehr passt nicht so
auf Folien. Wir haben ja zum Glück einige wenige Vorträge
im Seminar,
diesmal auch zuwerkte
Anschließend möchte ich Ihnen noch ein Werkzeug aus der Kategorie offene Software zeigen, Checkstyle.
Das ist eigentlich ein Werkzeug zur Prüfung von Quellcode bezüglich Programmierrichtlinien
. Das sagt ja auch der Name schon ein bisschen.
Und da kann man typischerweise sowas wie Namenskonventionen und Glaubenszukunfts-Modifier berühmen.
Und man kann eigene Regeln definieren. Und diese eigenen Regeln sind dann das,
was wir ganz gezielt einsetzen, für bestimmte Projekte.
Zum Beispiel, dass wir erlaubte Abhängigkeiten der Sollarchitektur hier ausdrücken.
Sie können tatsächlich, so ähnlich wie wir das hier eben auch hatten,
Sie könnten diese Regeln auch für Checkstyle formulieren und dann
so formulieren als Regeln für
Halt die Prüfung von Quellcode. Zusätzlich könnte man eine weitere Idee,
was man machen könnte,
man könnte auch fachliche Strukturierungen machen, wegen dieser Zugriffs-Modifier,
also Public oder Private oder Package-Private, diese Sichtbarkeitsbezeichnung,
die sie da kennen, die könnte man zufällig verwenden,
dass man im Rahmen OSGI ist, im Service-Standard,
dass wir sagen, was ist davon nach außen sichtbar und was ist nicht,
wird nicht zu viel sichtbar gemacht, wir können das prüfen.
Ja, und dann kann man rufen,
entspannt das unser der Service-Demplementierung,
unsere Service-Spezifikation
So, hier als Beispiel nochmal, dass nur so
den Quelltext zum Nachlesen, wieso würde das aussehen?
Das ist also XML. Und das wäre das Beispiel für
das Text für das Beispiel hier ebenfalls aus der gleichen Literatur genommen.
Ja, soweit erstmal dazu. Und damit sind wir
am Ende der Vorlesung. Vielen Dank fürs Mitmachen.
Vielen Dank für Ihre engagierten Fragen bei der Vorlesungsbesprechung.
Und ich freue mich auf Ihre Seminarbeiträge,
die wir vielleicht auch den einen oder anderen in Frage ja
den Studis zukommen lassen,
zugebessen.
Vielen Dank