Softwaretechnik, 11. Werkzeuge

Material für die Softwaretechnik Vorlesung, Mathias Pfeiffer und Bernhard Rumpe

Werkzeuge für die Softwareentwicklung

  • Software ist ein immaterieller Werkstoff.
  • Zur Erstellung, Weiterentwicklung, Bearbeitung, Verwaltung, Absicherung, etc. von Software benötigen wir verschiedenste Werkzeuge.
  • Manche dieser Werkzeuge sind interaktiv, wie zum Beispiel Editoren. Andere unterstützen die Automatisierung stetig sich wiederholender Aktivitäten. Wieder andere arbeiten voll automatisch im Hintergrund, um zum Beispiel die kontinuierliche Integration, das Testen und die Messung von Fortschritt und Qualität vorzunehmen.
  • Version: in einem evolutionären, linear fortschreitenden Projekt werden regelmäßig (quasi permanent) neue Versionen erzeugt.
  • Variante: sollte das Produkt in mehreren Varianten ausgeliefert werden, so sind diese Varianten gleichzeitig und parallel zu bearbeiten und gegebenenfalls weiterzuentwickeln.
  • Subversion (svn) ist ein hochwertiges Werkzeug zur Verwaltung von Software. Git setzt sich jedoch immer mehr durch. Grund ist u.A. steigender Komfort bei darauf aufbauender Funktionalität, wie zB. den Plattformen Github und GitLab.
  • Die RWTH bietet für ihre Angestellten und Studierenden kostenlos:

Git zeichnet sich besonders durch seine dezentrale Natur aus:

  • Jeder Entwickler besitzt eine vollständige Kopie des Repositories
  • Dies erlaubt die Gemeinsame gVerwaltung aber auch lokale Revisionen des Repositories

Das “Remote” Repository ist dabei auch nur ein “normales” Repository, dass typischerweise auf einem entfernten Server liegt. Wir schauen uns diesen Umstand im Selbstlernkurs genauer an.

  • Neu angelegte Dateien werden nicht automatisch von Git verwaltet, nicht “getracked”. Erst nach explizitem hinzufügen, “add”, stehen sie unter der Kontrolle von Git. Wird eine Datei verändert, gilt sie als modifiziert. Erst wenn diese Änderungen sozusagen in den Mittelpunkt gerückt werden, “gestaged werden”, werden sie in der nächsten Version berücksichtigt.
  • Git unterscheidet also lokal die vier gezeigten Zustände für einzelne Dateien
  • Und bietet Befehle diese Zustände zu verändern.

Je nach verwendeten Werkzeug im Frontend, können die genannten Befehle direkt per Kommandozeile, grafisch per Menü, oder aus einer Entwicklungsumgebung heraus gestartet werden.

  • Eine etwas ausführlichere Übersicht und eine reale Nachstellung der Befehle finden Sie auch im Selbstlernkurs.

  • Der Selbstlernkurs ist Teil des abfragbaren Basiswissens für die Klausur.

  • In dem dargestellten Sequenzdiagram arbeiten Anna und Bert parallel und weil Anna zunächst eincheckt, muss Bert seine lokale Version 14 (rot) mit Annas Version 15 mergen.

  • Das geht überraschend häufig automatisch, wie die nachfolgenden Folien zeigen. Probleme entstehen allerdings regelmäßig wenn nicht-ASCII/UTF-Files bearbeitet werden.

  • Merge klappt, weil zwar dieselbe Datei aber verschiedene Stellen bearbeitet werden.

Eine gemeinsame Verwaltung führt früher oder später zu Konflikten, weil parallel dieselbe Stelle bearbeitet wurde oder sehr viele Änderungen gleichzeitig vorgenommen wurden. Mechanismen zu deren Vermeidung und Behebung finden Sie im Selbstlernkurs.

  • Make liefert inkrementelle Kochrezepte. Eine kurze Übersicht der wesentlichen Bestandteile eines Make-Scripts finden Sie im Selbstlernkurs.

  • Kernbestandteil bei make ist der Aufbau des Abhängigkeitsgraphen für die Generierung von Dateien (links zu sehen). Daraus wird dann ein Bauplan realisiert, der die Dateien und zuletzt das Gesamtprogramm in adäquater Reihenfolge erzeugt.

  • Vorteil 1: make ist inkrementell, es wird also nur neu erzeugt, wenn die zu erzeugende Datei noch fehlt oder veraltet ist

  • Vorteil 2: make kann die Abhängigkeiten beliebig tief schachteln und breit verzweigen, erkennt zirkuläre Abhängigkeiten, und arbeitet mit vielen Betriebssystemen, Programmiersprachen und Generatoren zusammen.

  • Abhängigkeiten zu fremden Projekten kann make aber nicht von alleine lösen.

  • Größtes Problem von make ist allerdings, dass es mit dem teilweise in den Java Compiler integrierten Abhängigkeitsmanagement in Konflikt steht. Dieses problem existiert für die C/C++ Welt nicht, wo make hauptsächlich eingesetzt wird.

  • Maven behauptet von sich dasselbe zu tun wie Make, ist aber in Bezug auf Effizienz und Flexibilität ein dramatischer Rückschritt.

  • Einziger Vorteil: das Aktualisieren und Laden von vorgefertigten Bibliotheken, sowie (transitive) Aktualisierung von Nachbar-Projekten.

  • Statt einem intelligenten, bedarfsorientiert inkrementellen übersetzen nutzt Maven einen sturen 12 Phasenplan der immer von links bis zum jeweils angegebenen Ziel (z.B. “install”) durchgeführt wird.

    • Idealerweise sollte Maven nicht zum Einsatz kommen, Gradle oder Make sind deutlich besser.

  • Gradle baut inkrementell

  • Gradle bietet sehr ausgefeilte Mechanismen um den Abhängigkeitsgraph selbst zu erstellen

    • dazu wird in der ersten Phase das gradle Script ausgeführt und dadurch der Abhängigkeitskraft zwischen Artefakten so erzeugt, dass zu jedem neu zu erstellenden Artefakt bzw. ein Artefakt mit geänderten Quellen die jeweils notwendige Task aufgerufen werden kann.
  • Automatisierung benötigt über das Build- und Dependency-Management hinaus Werkzeuge, die regelmäßig eine Integration und Bereitstellung (Deployment) ausführen. Diese bieten:
    • Build-Stabilität
    • Modul-Integration
    • Automatisiertes Testen -> kurze Test-Zyklen
    • Qualitäts-Analysen: Code-Smells, Commit-Historie
    • Reporting – Benachrichtigung im Fehlerfall
    • Automatisierte Verteilung auf Testsysteme

  • GitHub Actions oder GitLab CI/CD bieten dafür allerlei Funktionalitäten an, die man zum großen Teil direkt über das Web-Interface konfigurieren kann.

  • Zur Erstellung einer eigenen CI/CD-Pipeline finden Sie weiterführende Inhalte im Selbstlernkurs.

  • Zahlreiche verschiedene Ansichten erlauben diverse Blicke sowohl für das Projektmanagement, als auch einzelne Entwickler und Entwicklerinnen.

  • Im Bild zu sehen ist ein Screenshot der Gruppe MontiCore – zu der sie übrigens herzlich eingeladen werden, wenn Sie bei uns am Lehrstuhl Software Engineering, der RWTH Aachen im Bereich einer studentischen Arbeit oder einer Promotion an MontiCore selbst, oder eines seiner Teilprojekte zur Werkzeugentwicklung, mitarbeiten möchten.

    • MontiCore besitzt einige Untergruppen und Projekte.
  • Dies ist ein Screenshot des MontiCore Projekts, bei dem man unter anderem sieht das aktuell 23 Branches verwaltet werden, insgesamt 7206 Commits (seit Umzug) gesetzt wurden und die Historie von MontiCore mittlerweile 28 GB Speicherplatz verbraucht. Außerdem zu sehen ist, dass die interne CI-Pipeline zur Übersetzung und Qualitätssicherung mithilfe von Tests aktuell auf Grün steht, während die Coverage noch nicht aktiviert war.

  • GitLab Issues: Ein unverzichtbares Werkzeug um offene Punkte, Fehlermeldungen, etc. zu verwalten und nicht zu vergessen.

  • GitLab Issues bietet die Möglichkeiten Ablaufdaten zu setzen, Labels, Meilensteine, Zuordnungen zu Iterationen, Gewichtung (Kritikalität) und vor allem auch einen Status zu verwalten.

  • GitLab Issues ist ein hilfreiches Mittel für alle Arten von Planungen, weshalb mittlerweile aufgrund der effizienten Nutzbarkeit und der kooperativen Umgangsformen auch ganz andere Projekte von Umzügen bis hin zu Parties (und übrigens auch Forschungsprojekte, Bachelor-, Master- und Doktorarbeiten) damit geplant werden.

  • In Kombination mit dem früher diskutierten automatisierten Merge lassen sich so auch hervorragend wissenschaftliche Papiere in LaTeX erstellen.

  • Es ist für Softwareentwicklerinnen und Softwareentwickler ein befriedigendes Gefühl, wenn man dem BurnDown-Chart ansieht, dass Issues erledigt werden und die Arbeit vorwärts geht.

Wir hoffen Ihnen hier sowohl einen Überblick über die breitere Landschaft der Softwareentwicklungstools gegeben zu haben, als auch weiterführendes Material für die aktuellen Grundlagen der Werkzeuge, die besonders relevant sind.

Join our mailing list for updates regarding courses and theses: