Software-Entwicklung

Inhaltsverzeichnis

1. Überblick

   Als Softwareentwickler habe ich in unterschiedlichen Projektkonstellationen gearbeitet und unterschiedliche Sprachen verwendet.

   1. Anpassung, Erweiterung, Ersatz von Berechnungsmodulen

      Projektnr.	Titel Bezeichnung	Sprache(n)	Zeitraum
      Projekt 22	Erweitertes Kalibrationsmodul für den Multiplate© Analyzer	ANSI-C, C++	2010
      Projekt 04	Anpassung und Erweiterung eines Programms zur offline -Simulation & -Steuerung eines Entwässerungskanals (im Hinblick auf den online Einsatz)	Fortran	1989-1990

   2. Programmierung von online-Berechnungsmodulen

      Projektnr.	Titel Bezeichnung	Sprache(n)	Zeitraum
      Projekt 13	Online-Vorhersage des Zustandes eines Mischwasserkanals unter Regenbelastung; Programm PREDICT (vgl. auch Quellenverzeichnis Software-Entwicklung)	Delphi	1998-2000
      Projekt 11	Online Prüfung der Konsistenz von Messdaten in einem Entwässerungskanal	Fortran	1993
      Projekt 09	Modul zur Steuerung eines Entwässerungskanals in der Praxis	Fortran	1992
      Projekt 02	Entwicklung von Modulen zur Aufbereitung von Radardaten	Fortran	1986-1987

   3. Programmierung von Testapplikationen

      Projektnr.	Titel Bezeichnung	Sprache(n)	Zeitraum
      Projekt 19	Validierung der verschlüsselten Kommunikation zwischen Chipkarte und Leser	C++	2007
      Projekt 16	Verifizierung des API-Frameworks auf Chipkarte	JavaCard	2003
      Projekt 15	Verifizierung von GlobalPlatform auf Chipkarte	JavaCard	2002

   4. Programmierung von eigenständigen Berechnungsapplikationen

      Projektnr.	Titel Bezeichnung	Sprache(n)	Zeitraum
      Projekt 13	Simulation von Entwässerungssystemen: Programm HYDROSIM (vgl. auch Quellenverzeichnis Software-Entwicklung)	Delphi, Fortran	1998-2000
      Projekt 12	Simulation von Entwässerungssystemen, Aufbereitung von Kanalnetzdaten.	Pascal, Fortran	1994-1998
      Projekt 03	Regelbasiertes System zur Steuerung von Entwässerungssystemen	Prolog	1987-1989

   Anm.: Weitere Informationen zum Inhalt der Berechnungsmodule können aus Seite Numerik/Algorithmik entnommen werden.

2. Sprache

   Eine Zäsur um das Jahr 1998 ereignete sich.

   1. Prozedurale Sprachen
      Vor 1998 wurden meistens prozedurale Sprachen eingesetzt.

      Projektnr.	Titel Bezeichnung	Sprache(n)
      12, 06	Numerische Lösungen von (Differential-)Gleichungssystemen, Modellierung von physikalischen Vorgängen in Entwässerungssystemen	Fortran, Pascal
      11, 02,	Datenanalyse mit Hilfe von Verfahren der Statistik, Approximationstheorie, Mustererkennung	Fortran, VBA
      09, 04, 03	Entscheidungsfindung mit Hilfe von regelbasierten Systemen, Optimierungsverfahren	Fortran, Prolog

      Diese Programme wurden fast ausschließlich im universitären Umfeld entwickelt - im Rahmen von Forschungsvorhaben oder im Anschluss an solche, um die Praxistauglichkeit der Ergebnisse zu sichern.

   2. Objektorientierte Sprachen
      

      Nach 1998 kommen überwiegend objekt-orientierte Sprachen im Einsatz.

      Projektnr.	Titel Bezeichnung	Sprache(n)
      22	Mehrpunkt-Kalibration, Approximationsalgorithmen	ANSI-C, C++
      19 16 15	Testanwendungen für Chipkarten	JavaCard, C++
      18	Formale Modellierung von Chipkarten	B-Methode
      13	Numerische Lösungen von Differentialgleichungssystemen, Modellvergleiche	Delphi
      von 14 bis 23	Datei-Manipulation, Test- Durchführung -Umformatierung -Generierung	ANSI-C, Perl, Python, proprietäre Skript-Sprachen wie ICC-Solutions

3. Diskussion

   1. Die Sprache C
      Im IT-Bereich - auch außerhalb der reinen eingebetteten Entwicklung - ist die C-Sprache nach wie vor ubiquitär.
      Exemplarisch für diese Situation ist ein kleines Projekt - weniger als 2 Monate - bei Giesecke & Devrient: Ziel war es, den Übersetzer einer firmeninternen Skriptsprache zur Durchführung von APDU-Tests zu verbessern und erweitern.

   2. Formale Modellierung von Chipkarten
      Ziel von Pilotprojekt 18 war die mathematische Modellierung von kritischen Teilen der GlobalPlatform Spezifikation - u.a. dem Kommando-Verteiler alias Command Dispatcher anhand der B-Methode. Die geschriebenen B-Modul-Dateien werden vom Tool LTG eingelesen, das daraus Testfälle generiert (Die Testgenerierung wird gedanklich als Beweisführung aufgefasst).

      Das Projekt wurde erfolgreich abgeschlossen: LTG konnte aus den Modellen Testfälle definieren.
      In der internationalen Arbeitsgruppe GlobalPlatform Test Specification (wo ich 2002 bis 2007 tätig war) lösten die Ergebnisse eine ernsthafte Diskussion darüber aus, ob nicht die gesamte Spezifikation - anhand einer formalen Sprache - umgeschrieben werden sollte. Das erstellte mathematische Modell würde das derzeit in Englisch verfasste Basisdokument künftig ersetzen.

      • Entscheidender Vorteil wäre, dass solches Modell automatisch (schnell) und vollständig auf Konsistenz und Vollständigkeit geprüft werden kann. Auch würden existierende Tools automatisch (schnell) lückenlose Testfälle - in fast beliebig großer Menge - daraus generieren.

      • Ein wesentlicher Nachteil war, dass die Erstellung von komplexen formalen Modellen mathematische und Programmier- Kenntnisse voraussetzt, welche diejenigen, die für die Spezifikation zuständig waren, nicht in erforderlichem Umfang besassen - bzw. nicht bereit waren, zu erwerben. D.h. ein komplett neuer Prozess für die Erstellung und Pflege der Spezifikation hätte definiert werden müssen.

        Bezogen auf das Testen erforderte die praktische Umsetzung der im Pilotprojekt 18 skizzierten Vorgehensweise, dass ein weiteres Problem gelöst würde: Die automatisch definierten Testfälle (weil sie möglicherweise so zahlreich sind) müssen automatisch für die automatische Durchführung übertragen werden. Die Aufbereitung der Testfälle hängt aber jeweils vom Tool, das für die Testdurchführung verwendet wird. Leider gab es damals keine weltweit standardisierte Skriptsprache. Sogar innerhalb eines Konzerns wie Giesecke&Devrient nutzten die Entwicklungsabteilungen jeweils unterschiedliche Tools (bzw. Skriptsprachen).

   3. Skriptsprachen vgl. Skriptsprachen
      

      Allgemeine Skriptsprachen sind beliebt, um Tools zu entwickeln. Vorteile sind:
      

      • Sie sind auf allen gängigen Betriebssystemen implementiert und frei - ohne Lizenzgebühr - verfügbar
      • Keine aufwändige Entwicklungsumgebung ist nötig. Viele Open-Source-Editierprogramme sind in der Lage ihre Syntax zu erkennen. Für interne Perl Projekte, arbeite ich gewöhnlich mit vim. Daher entstehen keine zusätzlichen Kosten bzw. entsteht kein (umständliches) Genehmigungsverfahren.
      • Erste Ergebnisse können vergleichsweise schnell erzielt werden (Prototyping).

      Anbei einige Beispiele, die den Anwendungsbereich solcher Tools verdeutlichen:

      • Im AGS-Projekt (23) war ich verantwortlich für Pflege und Weiterentwicklung eines Perl Programms zur Generierung von Schnittstellen-Tests.

      • Im -G&D-Projekt (17) habe ich ein Perl Programm geschrieben, das Testskripte von Format 'A' ins Format 'B' überträgt. Anlass war, dass Testengine 'A' neuere Funktionalitäten nicht unterstützte, die aber in Testengine 'B' integriert waren. Das Neuschreiben der vielen Tests hätten deutlich länger gedauert, als die Entwicklung eines Umformatierungsprogramms, das zudem - wenn es lesbar/modular geschrieben ist - für andere Umformatierungs- bzw. Analysen- Aufgaben wiederverwendet werden kann.

      • Im AGS-Projekt (23) schrieb ich Python-Module, um die Funktionalität des ECU-Testtools - das großteils in Python kodiert ist - zu erweitern.

      • In internen Perl Projekten habe ich bisher Perl vorzugsweise herangezogen, weil viele hilfreiche Funktionen von vornherein verfügbar sind.

      Allgemeine Skriptsprachen haben jedoch einen Nachteil, der nur eine (negative) Folgerung dessen ist, was ihre Stärke ausmacht: Codes, die ursprünglich als Prototypen entworfen wurden, wachsen im Laufe der Jahre enorm zu, erreichen eine Größe/Komplexität, die mit der Sprache und ihren Entwicklungsumgebungen schwierig zu handhaben wird.

      Im Beispiel aus der Tabelle unten hat sich der Quelltext innerhalb 5 Jahre fast verdreifacht.

      Version	LOC	Vergleichswert	Status	Infos
      1.x	3249	100 %	obsolet	Bordnetzkatalog im Format FIBEX 1.x
      2.x	6370	196 %	obsolet	Bordnetzkatalog im Format FIBEX 2.x
      3.x	7592	233 %	noch für einige Varianten verwendet.	Bordnetzkatalog im Format DBC
      4.x	9291	285 %	für immer mehr Varianten verwendet.	Bordnetzkatalog im Format FIBEX 4.1

      Tab. Wachstum eines Perl-Skripts (Beispiel aus dem AGS-Projekt (23), Stand 01.2016)
      Anmerkungen:
      1. LOC (Lines of Codes): Dieser Parameter charakterisiert den 'reinen' Quelltext, also ohne Kommentare, Leerzeilen oder eingebundene Module aus öffentlichen Bibliotheken - z.B. zur Handhabung des XML-Formates.
      2. Der Vergleichswert entspricht dem Code-Umfang prozentual im Vergleich zur Version 1.x.

      Der Code wurde aus verschiedenen Gründen geändert bzw. erweitert:

      • Die Quelldaten - z.B. der Bordnetzkatalog - wechseln im Laufe der Zeit das Format. (Dieser Umstand bestimmt insbesondere die Hauptversionsnummer).
      • Die Konsistenz der Eingabedaten muss immer aufwändiger geprüft werden. Ansonsten werden unspezifische Fehlermeldungen geworfen, und der Tester muss Zeit investieren, um potentielle Ursachen zu identifizieren.
      • Die Layer-Spezifikation berücksichtigt immer mehr Fälle, die immer komplexer formuliert werden.
      • Die HiL-Simulationsmodelle werden immer realistischer und erzwingen Abänderungen z.B. in der Aufbereitung von Signalwerten.
      • Die Testkonfiguration wird immer umfangreicher, um eine Generierung nach dem Wunsch des Testers zu steuern.

      Bei der Weiterentwicklung ist eiserne Disziplin nötig: Aussagekräftige Kommentierung, Modularisierung, Systematik der Bezeichnungen. Aus langer Sicht wäre eine Übertragung in C++ oder C# zu überlegen: Letztere Sprachen erzwingen eine strengere Strukturierung des Quelltextes und verfügen über bessere Programmierumgebungen. Vorerst müsste aber abgeklärt werden, ob und wie die Perl Bibliotheken oder gleichwertige einzubinden wären.

4. Referenzen zum Thema 'Software-Entwicklung'

   Zum Thema vgl. Khelil: Referenzen zur SW-Entwicklung.