Software Engineering in der Praxis - National Instruments Germany ...

Software Engineering in der Praxis –
Werkzeuge für optimierte LabVIEW-
Entwicklung
Abb.: Die grafische Entwicklungsumgebung NI LabVIEW
Kundenzitat:
"NI bietet im Umfeld von LabVIEW mittlerweile eine Vielzahl von Möglichkeiten, die die
Entwicklung im Team und die Einhaltung von Qualitätsstandards ermöglichen."
– Taubert Helge, Zühlke Engineering GmbH
Die Aufgabe:
Anwendung von Best Practices bei der Entwicklung mit LabVIEW
Die Lösung:
Betrachtet werden die Aspekte Requirements Management, Versionsverwaltung, Unit- und
Systemtests, statische und dynamische Code-Analyse und die Build-Automatisierung.
Autor(en):
Taubert Helge - Zühlke Engineering GmbH
ni.com/de

Kurzfassung
Software Engineering in klassischen Softwareentwicklungsprojekten – ohne den Einsatz von
LabVIEW – beinhaltet die Anwendung von Best Practices, die die Qualität der entwickelten
Software sicherstellen und die Entwicklung im Team überhaupt erst möglich machen. Dieser
Artikel beleuchtet, wie sich einige dieser Best Practices bei der Entwicklung mit LabVIEW
umsetzen lassen. Betrachtet werden die Aspekte Requirements Management,
Versionsverwaltung, Unit- und Systemtests, statische und dynamische Code-Analyse und die
Build-Automatisierung.
Requirements Management und Traceability
Mit dem Requirements Gateway existiert ein Werkzeug zur Verknüpfung der Anforderungen
mit Implementierung und Test. Als Quellen für Anforderungen werden diverse verbreitete
Requirements Management Tools als auch einfache Varianten auf Dokumentenbasis
unterstützt. Bei entsprechender Verlinkung der Anforderungen in den LabVIEW-VIs und
Testfällen sind mit dem Requirements Gateway Coverage und Impact-Analysen möglich. Die
Ergebnisse können visualisiert und als Report exportiert werden.
Versionsmanagement
Grundsätzlich gibt es zwei Ansätze, Versionsmanagement mit LabVIEW zu betreiben:
integriert in LabVIEW über einen Source-Control-Provider oder unabhängig von LabVIEW
auf Dateibasis mit einem beliebigen Versionierungssystem. Im integrierten Fall hängt die
Verwendbarkeit im Alltag stark davon ab, welche Möglichkeiten der Souce-Control-Provider
bietet. Hier kann es zu erheblichen Einschränkungen der Möglichkeiten gegenüber einer
nativen Nutzung des jeweiligen Versionskontrollsystems kommen. Ebenso muss häufig die
Arbeitsweise des Teams an die Möglichkeiten des Source-Control-Providers angepasst
werden, da diese häufig kaum Einstellmöglichkeiten bieten. Im aktiven Einsatz sind bei
manchen Source-Control-Providern Inkonsistenzen bezüglich des Source Control Status zu
beobachten, die zum Beispiel dazu führen können, dass ein VI nicht bearbeitbar ist, obwohl es
ausgecheckt wurde. Diese Inkonsistenzen können vermehrt auftreten, wenn zusätzlich mit
dem nativen Client des Versionskontrollsystems auf der gleichen Arbeitskopie gearbeitet
wird.
Verzichtet man auf die direkte Integration in LabVIEW und arbeitet nur mit den nativen
Clients der Versionskontrollsysteme, so bietet LabVIEW mit den mitgelieferten Tools
LVCompare und LVMerge die notwendigen Voraussetzungen, um mit einem
Versionierungssystem eine Integration für graphischen Diff und Merge durchzuführen. Diese
beiden Tools sind im Vergleich zu anderen Diff/Merge-Werkzeugen bei grafischen
Entwicklungsumgebungen weit ausgereift und bei entsprechender Parametrierung gut nutzbar.
Im Allgemeinen gibt es bei Versionskontrollsystemen unterschiedliche Strategien für den
Dateizugriff: Manche Systeme erlauben nur die exklusive Bearbeitung einer Datei durch
einen Benutzer, andere setzen auf parallele Bearbeitung mit nachfolgendem Merge.
Exklusiver Zugriff vermeidet die Notwendigkeit des Mergens, hat aber erhebliche Nachteile
bei der Arbeit im Team, wo es immer wieder zu Zugriffkonflikten und erhöhtem
Abstimmungsaufwand bei zentralen Dateien kommt. Beispielsweise sind die LabVIEW
Projektdateien zwar versionskontrollfreundlich als Text abgespeichert, enthalten aber sehr
ni.com/de

viele Detailinformationen, die ständige Modifikationen nach sich ziehen. Um
Zugriffskonflikte insgesamt zu vermeiden, bietet es sich an, die Programmfunktionalität auf
viele möglichst kleine VIs zu verteilen. Dadurch muss aber jedes Teammitglied häufig die
Projektdatei modifizieren, was dann wieder zu Zugriffskonflikten führt.
Ist die gleichzeitige Bearbeitung von Dateien durch das Versionskontrollsystem erlaubt,
entsteht häufig die Notwendigkeit, diese Änderungen zu mergen. Dies kann durch Aufteilung
der Funktionalität in viele kleine VIs minimiert werden. Ist es dennoch notwendig, leistet
LVMerge gute Dienste, wenn die Änderungen nicht zu stark die Struktur des VIs ändern.
Leider sind die VI-Eigenschaften beim Vergleich außen vor. Die LabVIEW-Projektdatei
kommt hier mit ihrem Textformat deutlich besser weg, da der Merge hier häufig problemlos
funktioniert. Konflikte sind allerdings durch den Detailgrad nicht zu vermeiden und
LabVIEW bietet keinerlei Unterstützung zur Auflösung dieser Konflikte. Daher bedarf es hier
in manchen Fällen genauer Kenntnisse des verwendeten XML-Formats.
Insgesamt stellen sich Punkte, wie die Verwendung von proprietären Binärformaten, der hohe
Detailgrad von manchen Dateien und teilweise fehlende Toolunterstützung beim Diff und
Merge, als Faktoren zur Reduzierung der Produktivität im Team heraus.
Test
Basis aller qualitätssichernden Maßnahmen im Bereich der Software-Engineering-Disziplin
Test sind Unittests. Das LabVIEW Unit Testing Framework bietet eine solide Grundlage für
die Erstellung, Verwaltung und Ausführung von Unittests. Setup- und Cleanup-VIs sowie
selbsterstelle Test-VIs bieten ausreichende Möglichkeiten zur Umsetzung einer Vielzahl von
Testszenarien. Die bei der Ausführung erstellte Codecoverage ermöglicht eine fundierte
Aussage über die erreichte Testtiefe und kann gut zur Bestimmung von Testende-Kriterien
herangezogen werden.
Fortgeschrittene Testszenarien erreichen allerdings schnell die Grenzen des Unit-Testing-
Frameworks. Als Beispiele seien die fehlende Unterstützung für kontinuierlich laufende VIs,
Events oder das Statemachine Toolkit genannt. Ebenso ist es bei komplexeren VIs nicht
möglich, Sub-VIs durch sogenannte Mocks zu ersetzen, um die Reaktion auf deren
Rückgaben gezielt zu prüfen.
Ein weiteres Manko ist, dass die Ausführung der einzelnen Testfälle nicht unabhängig
voneinander ist. Dies führt zu Problemen bei der Verwendung von nicht initialisierten Shift-
Registern zur Datenspeicherung, bei Feedback-Nodes und beim First-Call Operator.
Diese Einschränkungen machen deutlich, dass ein Design for Testability unabdingbar ist, um
die Vorteile nutzen zu können und einige der vorhandenen Schwächen auszugleichen.
GUI-Testing
Zur Unterstützung von Tests des graphischen User Interfaces einer LabVIEW-Applikation
bietet NI selbst keine Tool-Unterstützung an. Dennoch ist es grundsätzlich möglich, gängige
GUI Testing Tools einzusetzen. Um hier eine adäquate Testabdeckung zu erhalten ist
allerdings die Beschränkung auf die sogenannten System Controls notwendig. Etwas bessere
Unterstützung für die LabVIEW-native GUI-Elemente bietet das Tool „Ranorex“ mithilfe des
ni.com/de

LabVIEW Plugins von nte Systems. Aber auch hier werden viele Elemente nicht im Detail
unterstützt und man muss gegebenenfalls auf rein grafische Vergleiche zurückgreifen.
Dynamische Code-Analyse
Das Desktop Execution Trace Toolkit ist der Schlüssel zu vielfältigen Erkenntnissen über das
Laufzeitverhalten eines VIs und von LabVIEW im allgemeinen. Nach einer gewissen
Einarbeitungsphase bietet es reichhaltige Informationen über den genauen zeitlichen Ablauf
einer LabVIEW-Applikation. Der Trace ist essentiell zum Beispiel bei der Suche nach
Memory Leaks, Performance-Analysen und der Suche nach Absturzursachen. Die Detailtiefe
ist sehr fein konfigurierbar und mittels benutzerdefinierter Trace Events sind sehr detaillierte
Analysen möglich.
Statische Code-Analyse
Die Aufgabe der statischen Code-Analyse übernimmt der VI Analyzer. Er ermöglicht
detaillierte Analysen von einzelnen VIs bis hin zu ganzen Projekten. Dabei können die zu
prüfenden Regeln in der Konfiguration sehr fein eingestellt werden. Die verfügbaren
Prüfungen gehen von der Drahtführung über verdeckte Code-Teile bis hin zur Prüfung von
Standard- und LabVIEW-spezifischen Code-Metriken. Mithilfe der mitgelieferten API lassen
sich auch komplexe Analyseszenarien abbilden. Die minimale Granularität bei der Analyse ist
ein VI, einzelne Code-Blöcke lassen sich nicht von der Analyse ausnehmen. So ist es auch
nicht möglich, für einzelne Code-Blöcke Regeln außer Kraft zu setzen. In der Praxis kommen
daher eher Konfigurationen zum Einsatz, die wenige wichtige Regeln prüfen, da die Analyse
ansonsten eine unüberschaubare Anzahl an Regelverletzungen ergibt.
Build-Automatisierung
Zur kontinuierlichen Absicherung der Qualität werden in vielen Softwareprojekten
regelmäßige automatisierte Builds ausgeführt, bis hin zur sogenanntne Continuous
Integration, bei der jede Änderung am Versionskontroll-Repository einen Build auslöst. Ein
Build besteht dabei im Wesentlichen aus folgenden Schritten:
1. Abruf des Repositories in ein leeres Verzeichnis
2. Installation benötigter Tools für den Build
3. Erzeugen aller sogenanter Build-Artefakte aus den Quellen
4. Installation der erzeugten Bibliotheken und Programme
5. Ausführung von Tests
6. Erstellung eines oder mehrerer Reports.
Spielt in einem solchen Szenario LabVIEW eine Rolle, kommen verschiedene Aspekte zum
Tragen. Solche Builds sind üblicherweise kommandozeilenorientiert. VIs können ohne
Erzeugung eines Executables direkt in der LabVIEW-Entwicklungsumgebung ausgeführt
werden. LabVIEW bietet dabei Unterstützung für die Auswertung von Kommandozeilen-
Parametern. Es ist aber notwendig, vor dem Aufruf sicher zu stellen, das die Runtime Engine
wirklich nicht läuft, sonst sind die Parameter nicht verfügbar. Ausgaben auf die Konsole für
die Reporterstellung gehen nur über einen Aufruf der Windows-API. Die LabVIEW
Community bietet jedoch VIs dafür an. Den Returncode kann man nicht wie in der
ni.com/de

Kommandozeilenwelt üblich zur Rückgabe von Fehlern verwenden, dazu muss ein separater
Mechanismus definiert werden.
Muss der Build auch Executables und Installer aus LabVIEW-Projekten erzeugen, kommt der
ApplicationBuilder zum Einsatz. Er beinhaltet auch ein VI zum Aufruf von Build-
Spezifikationen aus einem Projekt, was ihn skriptfähig macht. Leider sind häufig zusätzliche
Schritte notwendig, um den ApplicationBuilder erfolgreich in einen Build zu integrieren. Die
Probleme beginnen bei der Verwendung von absoluten Pfaden in den Build-Spezifikationen.
Diese müssen an die Gegebenheiten auf dem sogenannten Build-Rechner angepasst werden.
Dies ist grundsätzlich über Property-Nodes eines Projektes möglich, allerdings sind diese
Properties kaum dokumentiert und man ist häufig auf Trial-and-Error und Workarounds
angewiesen. Enthält ein Projekt externe Abhängigkeiten zum Beispiel zu .NET Assemblies,
die im Rahmen des Builds neu erzeugt werden, müssen zunächst die Referenzen im
LabVIEW-Projekt und den beteiligten VIs aktualisiert werden. Dies ist durch Laden des
Projektes und Speichern der modifizierten VIs per Skript möglich, muss aber als extra Schritt
vor dem Aufruf des ApplicationBuilders durchgeführt werden.
Hat man dann im Rahmen der Builds die benötigen Installer erzeugt, lassen sich diese per
Kommandozeile auch ohne Benutzerinteraktion unter eventueller Angabe einer
Parameterdatei installieren. Damit sind dann die Voraussetzungen erfüllt, um in die Testphase
des Builds überzugehen.
LabVIEW lässt sich in einen solchen typischen automatisierten Build einbinden. Die gebotene
Unterstützung für solche Szenarien ist allerdings nicht sehr komfortabel. Daher ist mit
Mehraufwand für die Realisierung gegenüber klassischen Werkzeugketten zu rechnen, der in
der Projektplanung berücksichtigt werden muss.
Zusammenfassung
NI bietet im Umfeld von LabVIEW mittlerweile eine Vielzahl von Möglichkeiten, die die
Entwicklung im Team und die Einhaltung von Qualitätsstandards ermöglichen. Die Kenntniss
dieser Möglichkeiten und der Produktiveinsatz empfehlen sich für jedes professionell
durchgeführte Entwicklungsprojekt mit LabVIEW. Vorhandene Schwächen müssen mit
Mehraufwand umgangen werden oder machen den Einsatz mancher Best Practices
unmöglich. Hier bleibt abzuwarten, was zukünftige Versionen an Verbesserungen bringen.
Autor:
Taubert Helge
Zühlke Engineering GmbH
Düsseldorfer Straße 40a
Eschborn D-65760
Deutschland
Tel: +49 6196 77754-0
helge.taubert@zuehlke.com
Nächste Schritte
Unter folgendem Link finden Sie die eingesetzte NI-Software:
ni.com/de

Zum Referenzsystem »
Testen Sie LabVIEW: Evaluierungsversion zum Download »
LabVIEW Homepage »
Ressourcen zum Software-Engineering-Prozess mit LabVIEW:
Webcast: Große Projekte mit der LabVIEW-Plattform entwickeln »
Technische Bibliothek "Advanced Application Development with LabVIEW" »
Trainingskurse:
Kurs "Managing Software Engineering in LabVIEW" »
Kurs "Advanced Architectures for LabVIEW" »
RF-Produkte von National Instruments »
Fragen?
Sie suchen eine Lösung für Ihr Mess- oder Prüfsystem? Sie wünschen Informationen für Ihre
spezielle Applikation?
E-Mail-Kontaktformular: Wir beraten Sie gerne und unverbindlich! »
NI-Produktübersicht
Seit mehr als 20 Jahren gehört National Instruments zu den Vorreitern im Bereich der Mess-
und Automatisierungstechnik. Wir haben hier unsere Hard- und Software kompakt für Sie
zusammengestellt.
PDF zum Download »
Mein Benutzerprofil | RSS | Datenschutz | AGB | Kontakt © 2011 National Instruments Corporation. All rights reserved.
| Seite empfehlen
ni.com/de