Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software

4,981 views

Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software

  1. 1. Einsatz von Subversion bei der Entwicklung technisch-wissenschaftlicher Software SubConf 2007 (17.-18.10.2007, München) Andreas Schreiber < Andreas.Schreiber@dlr.de> Deutsches Zentrum für Luft- und Raumfahrt e.V., Köln-Porz http://www.dlr.de/sc/verteiltesysteme
  2. 2. Übersicht <ul><li>Das DLR </li></ul><ul><li>Software-Entwicklungen in Luftfahrt, Raumfahrt und Schiffbau </li></ul><ul><li>Wissenschaftliche Software-Entwicklung </li></ul><ul><li>Tool-basierter Entwicklungsprozess mit Subversion </li></ul><ul><li>SVNChecker </li></ul><ul><li>Zusammenfassung </li></ul>
  3. 3. <ul><li>Das DLR </li></ul><ul><li>Deutsches Zentrum für Luft- und Raumfahrt Raumfahrt-Agentur der Bundesrepublik Deutschland </li></ul>
  4. 4. Zahlen zum DLR <ul><li>DLR ist die größte deutsche Forschungseinrichtung </li></ul><ul><li>5.300 Mitarbeiter arbeiten in 28 Forschungsinstituten und Einrichtungen </li></ul><ul><ul><li> 8 Standorten, </li></ul></ul><ul><ul><li>7 Außenstellen. </li></ul></ul><ul><li>Kernkompetenz des DLR liegt im Bereich Ingenieurwissenschaften </li></ul><ul><li>Mehr als 1000 DLR-Mitarbeiter entwickeln Software </li></ul><ul><li> DLR ist eines der größten Softwarehäuser Deutschlands! </li></ul> Köln - Porz  Lampoldshausen  Stuttgart  Oberpfaffenhofen Braunschweig   Göttingen Berlin- -  Adlershof  Bonn Trauen   Hamburg  Neustrelitz Weilheim  Berlin- Charlottenburg   Sankt Augustin  Darmstadt Bremen 
  5. 5. Software-Entwicklungen in Luft- und Raumfahrt Klassifizierung <ul><li>Software für missionskritische Systeme </li></ul><ul><ul><li>Embedded Software und Real-Time-Software in Flugzeugen, Satelliten, Raumfahrzeugen, … </li></ul></ul><ul><li>Software mit großen Userzahlen </li></ul><ul><ul><li>Internet/Intranet/Email, Webshop für Satellitendaten </li></ul></ul><ul><li>Software mit großem Anteil an der Wertschöpfungskette </li></ul><ul><ul><li>Prozessunterstützung, Datenmanagement, Modellierungs- und Simulationsumgebungen, … </li></ul></ul><ul><li>Software deren Effizienz sich unmittelbar auf die Betriebskosten auswirkt </li></ul><ul><ul><li>Numerische Simulationscodes </li></ul></ul>
  6. 6. Beispiele für Entwicklungen <ul><li>Luftfahrt </li></ul><ul><li>Strömungssimulation mit dem FlowSimulator </li></ul><ul><li>Schiffbau </li></ul><ul><li>Schiffsentwurfs- und Simulationssystem SESIS </li></ul>Quelle: Flensburger Schiffbau-Gesellschaft mbH & Co. KG Quelle: DLR, Institut für Aerodynamik und Strömungstechnik
  7. 7. Luftfahrt Simulation von Flugzeugen <ul><li>Viele komplexe Probleme erfordern hochgenaue numerische Simulationen mit vielen Verarbeitungsschritten </li></ul><ul><li>Hochgenaue Simulation erfordert Kopplung vieler Fachdisziplinen </li></ul><ul><li>Strömung – Struktur – Wärme – Flugmechanik – Radarsignatur – Infrarotsignatur … </li></ul><ul><li>Solche Rechnungen werden softwaretechnisch ständig komplexer </li></ul><ul><ul><li>Komplexe Simulationscodes </li></ul></ul><ul><ul><li>Komplexes Datenmanagement </li></ul></ul>
  8. 8. Beispiele für Simulationscodes Hochgenaue CFD-Löser <ul><li>Beispiele für hochgenaue CFD-Löser </li></ul><ul><ul><li>DLR TAU-Code (siehe http://www.dlr.de/as/ ) </li></ul></ul><ul><ul><li>ONERA elsA-Code (siehe http://elsa.onera.fr ) </li></ul></ul><ul><li>Geeignet für komplexe Geometrien: </li></ul>DLR F4 Wing Body Eurofighter mit Last
  9. 9. Simulationsmanagement FlowSimulator <ul><li>Parallele Datenstrukturen </li></ul><ul><li>Implementierung in C++ und Python </li></ul><ul><li>Gemeinsame Datenhaltung und einheitlicher Datenaustausch zwischen Tools in CFD-Prozessketten </li></ul><ul><li>Entwicklung im verteilten Team: </li></ul><ul><ul><li>Airbus ( Koordination ) </li></ul></ul><ul><ul><li>ARA, CERFACS, DLR, ONERA, BAE-ATC, EADS-MAS, QinetiQ, SOGETi </li></ul></ul><ul><li>Nutzung von Subversion (Repository im DLR) </li></ul>
  10. 10. Schiffbau Entwurf von Schiffen <ul><li>Nationales Schiffbauprojekt SESIS </li></ul><ul><li>Anwendung: Früher Schiffentwurf („ design in seven days “) </li></ul><ul><ul><li>Frühes Design zur Angebotserstellung </li></ul></ul><ul><ul><li>Verkürzung der Entwurfszeiten </li></ul></ul><ul><ul><li>Simulation der Hauptkomponenten </li></ul></ul><ul><li>Werften organisieren Schiffbauprozess </li></ul><ul><li>Integration der Zulieferer in den Designprozess </li></ul><ul><li>http://www.sesis.de </li></ul>Quelle: Flensburger Schiffbau-Gesellschaft mbH & Co. KG Quelle: Lindenau GmbH Schiffsweft & Maschinenfabrik
  11. 11. Schiffsentwurfs- und Simulationssystem <ul><li>Verteiltes System </li></ul><ul><ul><li>Nutzung von Eclipse/OSGi </li></ul></ul><ul><ul><li>Flexible Kommunikation (CORBA, Grid-Services, …) </li></ul></ul><ul><li>Offen für beliebige Erweiterbarkeit durch Werften, Zulieferer, … </li></ul><ul><li>Entwicklung im verteilten Team: </li></ul><ul><ul><li>DLR ( Koordination ) </li></ul></ul><ul><ul><li>Fraunhofer SCAI, Flensburger Schiffbau Gesellschaft, Lindenau Schiffswerft, SAM Electronics, CMT, TU HH </li></ul></ul><ul><li>Nutzung von Subversion (Repository im DLR) </li></ul>JVM SESIS/RCE Eclipse/OSGi Komm. Broker Priv. Update Plug-In Bundle E4-Methode JVM SESIS/RCE Eclipse/OSGi Komm. Broker Priv. Update Bundle JVM SESIS/RCE Eclipse/OSGi Komm. Broker Priv. Update Plug-In GUI Ingenieur- Arbeitsplatz Compute- Server Datenbank- Server
  12. 12. Beispiel-Anwendung: Gewichtsverteilung im Schiff
  13. 13. Wissenschaftliche Software-Entwicklung Beobachtungen aus der täglichen Praxis… <ul><li>Typisches Phänomen: Entwicklungen fangen klein an („kurzes Skript“) aber wachsen oft zu großen Software-Systemen heran </li></ul><ul><li>Teamgröße : Von 1 Student bis >50 Wissenschaftler aus mehreren Instituten </li></ul><ul><li>Viele Wissenschaftler (z.B. Mathematiker, Physiker, Ingenieure) haben keinerlei Software-Engineering-Ausbildung aber entwickeln große Software-Pakete! </li></ul><ul><li>Ihr Ziel : Möglichst schnelles Umsetzen ihrer Ideen in laufenden Code </li></ul><ul><li>Produktivitätsverlust durch archaische Tools und Vorgehensweisen </li></ul><ul><ul><li>z.B. Alte Texteditoren (vi, Emacs, Notepad) </li></ul></ul><ul><ul><li>z.B. Austausch von Code über E-Mail, Memory-Sticks oder NFS </li></ul></ul><ul><ul><li>z.B. kein systematischer Test </li></ul></ul>
  14. 14. Wissenschaftliche Software-Entwicklung „Begründungen“ <ul><li>Weit verbreitete Vorurteile </li></ul><ul><li>Vorurteil 1: „Wir brauchen keine Qualitätssicherung“ </li></ul><ul><li>Vorurteil 2: „Für Software-Engineering haben wir kein Geld“ </li></ul><ul><li>Vorurteil 3: „Software-Engineering mindert den Spaß-Faktor“ </li></ul>
  15. 15. Weit verbreitete Vorurteile <ul><li>Vorurteil 1: „Wir brauchen keine Qualitätssicherung“ </li></ul><ul><li>Jeder vernünftige SW-Entwickler betreibt QS: </li></ul><ul><ul><li>Datensicherung </li></ul></ul><ul><ul><li>Versionierung (Filesystem oder CVS etc.) </li></ul></ul><ul><ul><li>Dokumentation </li></ul></ul><ul><ul><li>Benutzerinformation </li></ul></ul><ul><li>Spezieller Projektcharakter bestimmt Art und Umfang vernünftiger QS-Maßnahmen </li></ul>
  16. 16. Weit verbreitete Vorurteile <ul><li>Vorurteil 2: „Für Software-Engineering haben wir kein Geld“ </li></ul><ul><li>Software-Engineering spart Geld: </li></ul><ul><ul><li>Überraschungen in späteren Phasen (Implementierung) vermeiden durch professionelle Planung </li></ul></ul><ul><ul><li>Koordinierung mehrerer Entwickler </li></ul></ul><ul><ul><li>Beschleunigung der Entwicklung durch Tool-Einsatz </li></ul></ul><ul><ul><li>Vereinfachte Erweiterbarkeit </li></ul></ul><ul><ul><li>Wiederverwendbarkeit </li></ul></ul><ul><li>Durch Verzicht auf Software-Engineering wird kein Geld gespart sondern verschwendet. </li></ul>
  17. 17. Weit verbreitete Vorurteile <ul><li>Vorurteil 3: „Software-Engineering mindert den Spaß-Faktor“ </li></ul><ul><li>Software-Engineering verhindert lästige Probleme, z.B.: </li></ul><ul><ul><li>Fehler im eigenen Code durch Änderungen anderer Entwickler </li></ul></ul><ul><ul><li>Unüberschaubarkeit großer Codes (insbesondere nach Personalwechsel) </li></ul></ul><ul><ul><li>Globale Auswirkungen lokaler Code-Änderungen (Spaghetti-Code) </li></ul></ul><ul><li>SW-Engineering schafft Zeit für inhaltliche Arbeit </li></ul><ul><li>SW-Engineering-Erfahrung hilft bei späteren Bewerbungen </li></ul>
  18. 18. Real Programmers <ul><li>Früher: „The REAL programmer was happy with a keypunch, a Fortran IV compiler and a beer“ </li></ul><ul><li>Heute: Immense Produktivitätssteigerung durch die Nutzung von IDEs und weiteren Software-Werkzeugen </li></ul><ul><ul><li>In der Wissenschaft gibt es noch viele REAL programmers … </li></ul></ul>(Quelle: http://www.travelnotes.de/rays/fortran/fortran.htm)
  19. 19. Software Engineering für Wissenschaftler <ul><li>Umfassende QS-Vorgaben nicht sinnvoll, aber: </li></ul><ul><ul><li>Mindestanforderungen ( Minimal-Standards ) sollten erfüllt sein </li></ul></ul><ul><li>Vorschläge für: </li></ul><ul><ul><li>Prozess (abgeleitet vom V-Modell/V-Modell XT) </li></ul></ul><ul><ul><li>Entwicklungs-Tools </li></ul></ul><ul><li>Anpassbarkeit an vorhandene Tools und Wünsche der Kollegen </li></ul><ul><li>Schrittweise Einführung muss möglich sein </li></ul><ul><li>Minimum: Nutzung eines Repositories </li></ul>The Tao of Source Control: “If it’s not in the repository, it doesn’t exist.” Integrations- test Teilsystem- integration System- Integration Modultest Teilsystem- beschreibung Architektur Design Fein- Design Beschreibung Implementierung
  20. 20. Implementierungsphase Dokumentation TODO-Liste Changelog … Test- Entw. Code Test- Abarb. TODO-Liste Neueintrag Aktualisierung Spezifi- kation Entwickler Koordinator Überwachung / Feedback
  21. 21. Coding Prozess Prozesskette für den Entwickler Bug-/Issue- Tracking Version control Checkstyle Build-tool Checks Source code Source code Source code Code Review Profiling Code coverage Deployment IDE Auditing verification assignment verification Unit test Unit test Unit test
  22. 22. Versionsverwaltung mit Subversion <ul><li>Subversion wird häufig im techn.-wiss. Bereich eingesetzt </li></ul><ul><li>Warum? </li></ul><ul><li>Ähnlichkeit zum verbreiteten CVS </li></ul><ul><li>Frei verfügbar (Open-Source) </li></ul><ul><li>Viele Installations-Optionen auf Server-Seite (WebDAV) </li></ul><ul><li>Gute Integration in IDEs und große Auswahl an Client-Tools Z.B. Integration in Windows-Explorer </li></ul>
  23. 23. Subversion im DLR <ul><li>Lokaler Einsatz in vielen Instituten und Projekten </li></ul><ul><ul><li>Viele Installationen, betreut durch IT-Manager der Institute </li></ul></ul><ul><ul><li>Angepasst an Erfordernisse der Institute/Projekte </li></ul></ul><ul><li>Bereitstellung als zentrale Plattform </li></ul><ul><ul><li>Beauftragt durch DLR Informations- und Kommunikations-Management </li></ul></ul><ul><ul><li>Bereitgestellt durch IT-Dienstleister T-Systems Solutions for Research GmbH </li></ul></ul><ul><ul><li>Vorerst nur „Standard-Konfiguration“ (z.B. keine Hook-Skripte) </li></ul></ul><ul><li>Zur Zeit Migration von CVS-Repositories nach Subversion </li></ul>
  24. 24. Tool-Infrastruktur <ul><li>Prozessunterstützung durch geeignete Software-Engineering-Werkzeuge </li></ul><ul><li>Unterstützung u.a. für </li></ul><ul><ul><li>Release-Planung </li></ul></ul><ul><ul><li>Problem-, Änderungs- und Anforderungsmanagement </li></ul></ul><ul><ul><li>Versionsverwaltung </li></ul></ul><ul><ul><li>Code-Analyse </li></ul></ul><ul><ul><li>Test, Build, Deployment </li></ul></ul><ul><ul><li>Nightly Builds </li></ul></ul><ul><li>Integration mit Editor bzw. Entwicklungsumgebung (IDE) </li></ul>Angepasst an Randbedingungen (Programmiersprachen, QS-Anforderungen etc.)
  25. 25. Beispiel: Infrastruktur mit Open-Source-Tools Entwicklungsumgebung und Web-Schnittstellen Wiki MoinMoin Issue-Tracking MANTIS IDE z.B. Eclipse Repository Browser ViewVC Test- und Verifikations- tools Check Test Build Status CruiseControl Schrittweise Einführung möglich! Automatische Builds und Tests
  26. 26. Automatische Überprüfung beim Commit Source-Code-Check auf Server-Seite <ul><li>Überprüfungen beim Commit ins Versionsmanagement </li></ul><ul><ul><li>Berechtigungen </li></ul></ul><ul><ul><li>Kodierrichtlinien </li></ul></ul><ul><ul><li>Test-Abdeckung </li></ul></ul><ul><ul><li>Bugs / Code-Schwächen </li></ul></ul><ul><ul><li>Gültige Issue-ID </li></ul></ul><ul><li>Bei „Fehlern“ erfolgt Abbruch </li></ul><ul><li>Protokollierung, z.B. </li></ul><ul><ul><li>Commit-Datenbank (SQL): bei Erfolg </li></ul></ul><ul><ul><li>Log-Datei: immer </li></ul></ul><ul><ul><li>Mail-Benachrichtigung: immer </li></ul></ul> Ein Check nicht bestanden IDE z.B. Eclipse Commit Check
  27. 27. SVNChecker Hook-Skripte für Subversion <ul><li>Aufgaben </li></ul><ul><li>Integration von Versionsverwaltung in die Arbeitsumgebung </li></ul><ul><li>Insbesondere Verbindung zum Issue/Bug-Tracking-System </li></ul><ul><li>Allgemein verwendbar für beliebige Aufgaben </li></ul><ul><li>Nutzung </li></ul><ul><li>Aufruf als Hook-Skript in Subversion ( pre-commit , post-commit ) </li></ul><ul><li>Externe Tools werden durch Plug-Ins angebunden </li></ul><ul><li>Verfügbarkeit </li></ul><ul><li>Entwickelt im DLR </li></ul><ul><li>Verfügbar als Open-Source (Apache License V2.0) </li></ul><ul><li>https://sourceforge.net/projects/svnchecker/ </li></ul>
  28. 28. SVNChecker Implementierung <ul><li>Implementierung als erweiterbares Framework </li></ul><ul><li>Kein Server-Prozess notwendig </li></ul><ul><li>Aufruf aus Subversion-Hook-Skript: </li></ul><ul><li>Entwicklung in Python </li></ul><ul><li>Sehr einfach zu lernen und zu benutzen ( = steile Lernkurve ) </li></ul><ul><li>Erlaubt eine schnelle Entwicklung ( = geringe Entwicklungszeit ) </li></ul><ul><li>Ausgezeichnete Wartbarkeit ( = Qualitätssicherung ) </li></ul>#!/bin/sh python svnchecker/Main.py PreCommit $1 $2 || exit 1
  29. 29. SVNChecker Architektur SVNChecker Transaction Check 1 Check 2 Check 3 Transaction Message Exit-code Handler A Handler B Handler C Exit-Code ● ● ● ● ● ● Externe Tools Externe Tools Subversion Repository Hook Script
  30. 30. Beispiele für Überprüfungen („Checks“) <ul><li>Mögliche Überprüfungen von Source-Code oder sonstigen Randbedingungen </li></ul><ul><li>Kodierrichtlinien </li></ul><ul><ul><li>Aufruf von Checkstyle (Java) oder Pylint (Python) </li></ul></ul><ul><li>Source-Code-Analyse </li></ul><ul><ul><li>Aufruf von Findbugs (Java) oder QS C/C++ </li></ul></ul><ul><li>Rechte </li></ul><ul><ul><li>Überprüfung von Rechten des Benutzers auf das gesamte Repository, einzelne Verzeichnisse oder einzelne Dateien </li></ul></ul><ul><li>Issue/Bug-Tracking </li></ul><ul><ul><li>Überprüfung auf Gültigkeit von IDs </li></ul></ul>
  31. 31. Beispiele für Aktionen („Handler“) <ul><li>Mögliche Ausgabe-Ziele für Ergebnisse der Repository-Vorgänge und SVNChecker-Checks: </li></ul><ul><li>E-Mail-Versand </li></ul><ul><li>Aktualisierung einer Log-Datei </li></ul><ul><li>Konsolen-Ausgabe </li></ul><ul><li>Eintrage in Datenbank („Commit-Datenbank“) </li></ul><ul><li>Eintrag ins Issue/Bug-Tracking-System </li></ul><ul><li>Aktualisierung eines RSS-Feeds </li></ul><ul><li>Weblog-Post </li></ul>
  32. 32. SVNChecker Weitere Entwicklungen <ul><li>Ergänzung um Features anderer ähnlicher Produkte </li></ul><ul><li>Z.B. Scmbug (Perl-Software  ) </li></ul><ul><li>Verallgemeinerung für beliebige Versionsmanagement-Systeme </li></ul><ul><li>ClearCase, CVS, Git, Perforce, … </li></ul><ul><li>Vollständige Nachvollziehbarkeit von Software-Entwicklungsprozessen </li></ul><ul><li>Integration einer Provenance-Aufzeichnung ( http://www.gridprovenance.org ) </li></ul><ul><li>GUI zur Konfiguration </li></ul><ul><li>Web-basiertes Tool (mit Google Web Toolkit) </li></ul>
  33. 33. Zusammenfassung <ul><li>Entwicklung technisch wissenschaftlicher Software wird ständig komplexer </li></ul><ul><li>Wissenschaftler müssen sich zunehmend mit Software-Engineering beschäftigen </li></ul><ul><li>Software-Engineering-Verfahren für Wissenschaftler sollten schrittweise und problemangepasst eingeführt werden </li></ul><ul><li>Als Minimum sollte ein Versionsmanagement bereitgestellt werden </li></ul><ul><li>Subversion wird in wissenschaftlichen Projekten häufig eingesetzt </li></ul><ul><li>SVNChecker zur Integration von Subversion in die Arbeitsumgebung </li></ul>
  34. 34. Am Ende… Hinweise <ul><li>pyCologne: Python User Group Köln </li></ul><ul><ul><li>Monatliche Treffen von Python-Interessierten aus dem Großraum Köln </li></ul></ul><ul><ul><li>http://www.pycologne.de </li></ul></ul><ul><li>Interesse an spannenden Tätigkeiten in Luft- und Raumfahrt? </li></ul><ul><ul><li>Feste Mitarbeit </li></ul></ul><ul><ul><li>Diplomarbeiten, Praktika </li></ul></ul><ul><ul><li>https://wiki.sistec.dlr.de/StellenAusschreibungen </li></ul></ul>

×