Embedded Software als integriertes Paket

Anbieter zum Thema

“CMock” ist ein natürlicher Begleiter von “Unity”, einem C-Programm, das für das einzelne Testen von Softwaremodulen konzipiert ist. Die beiden lassen sich sehr gut zusammen verwenden und sind fundamentale Säulen einer testgesteuerten Entwicklung (TDD, “Test Driven Development”. (Bild 2 in der Bildergalerie)

Nach diesem Vorgang werden die Tests für die Überprüfung der Funktionen eines Software Modules vor der Implementierung dieses Moduls festgestellt und festgehalten.

Dies ermöglicht, dass die Spezifikation überprüft wird, um sicher zu stellen dass diese konform mit den Anforderungen ist. Die Implementierung des Moduls wird damit die einfachste sein, die die definierten Tests erfolgreich übersteht.

Die hauptsächliche Schwierigkeit besteht darin, einen Satz an Tests zu generieren, welcher die unterschiedlichen Funktionen des Moduls von allen Seiten in Anspruch nimmt und dies unabhängig von der Implementierung prüft. Der Vorteil dabei ist, dass die Implementierung tendenziell minimal gehalten werden kann und somit eine einfachere Lösung des Problems beinhaltet. Die zukünftige Verwaltung der Software wird somit dank dieser effizienteren Vorgehensweise vereinfacht.

Gleichzeitig dient die stets wachsende Anzahl an Testvorgängen, die bei jeder Änderung automatisch durchgeführt werden können, dazu, dass eventuelle Probleme oder unerwünschte Nebeneffekte, die nach einer Änderung in der Implementierung unbewusst eingeführt wurden, sehr schnell in dem automatischen Testvorgang identifiziert werden.

Innerhalb einer größeren Gruppe, stellt sich dann das Problem, wie die Kollaboration unter Entwicklern gestalten werden kann. Dazu gibt es zum Glück professionelle Tools wie “Bitbucket” von Atlassian oder “Mercurial”. Diese können sich als graphische Benutzeroberfläche mit anderen Tools, wie das bekannte „GIT“ verbinden, und die Versionsverwaltung von Dateien vereinfachen.

Um den Kreis um die Tool-Landschaft zu schließen: Es gibt zusätzliche Möglichkeiten, die man zum Erfolg einsetzen kann. Programme wie „TeamCity“ sind für eine kontinuierliche Integration von Softwaremodulen sehr gut geeignet und unterstützen ein automatisiertes Testverfahren, das bei jeder gespeicherter Änderung in der Software eingeleitet wird. Des weiteren unterstützt “Scons” die Generierung von mehreren Versionen von Software, für unterschiedliche Compiler Umgebungen oder Hardware Plattformen.

Das Tool „LDRA” kann eingesetzt werden, um eine statische Programmanalyse durchzuführen, um die Konsistenz mit anderen Entwicklungsstandard und Regeln, wie von MISRA-C spezifiziert, zu überprüfen. Dasselbe Tool kann auch eine dynamische Analyse vornehmen, um die Abdeckung der Implementierung bei jedem Test-Aufruf zu prüfen und dabei sicherstellen, dass die gesamten Funktionen in Anspruch genommen werden und es keine Teile im Software Modul gibt, die nicht benutzt werden.

Alle solche Programme sind die fundamentalen Bausteine, die relevant sind, um ein automatisiertes Testen und die dazugehörige Berichtserstellung zu ermöglichen, mit dem Ziel den Entwickler von diesen Tätigkeiten zu befreien und ihm mehr Zeit einräumen, um seiner Hauptverantwortung nachgehen zu können: eine effiziente und gut konzipierte Software zu schreiben.

Wie könnte dann ein Vorgang aussehen, um eine gute und effiziente Softwarearchitektur zu definieren?

Ein modulares Konzept ist eine natürliche Konsequenz des Bedarfs, ein komplexes Problem in einen Satz von einfacheren Elementen zu partitionieren.

Anforderungen richtig spezifizieren

Ein Element der Software kann man gut mit einem Modul und dessen Schnittstelle identifizieren. Damit kann man die Abhängigkeiten der Module reduzieren, den Aufwand für die Pflege der Software geringer halten und das Einzeltesten der Module ermöglichen.

Der IEC/ISO/IEEE-12207 Standard (“Systems and software engineering - Software life cycle processes”) ist an dieser Stelle eine große Hilfe, um den Entwicklungsfluss zu definieren, da es die Feststellung einer Spezifikation der Anforderungen, der Gestalt und des Testverfahrens verlangt.

Wie kann man in der Praxis ein Modul definieren? Ein Modul ist ein Basis-Baustein, der mit dem Konzept von Bereitstellen und Benötigen von Dienste zusammenhängt. Damit ist es möglich eine hierarchische und flexible Lösungen zusammensetzen. Einige Module könnten keine Dienste von untergeordneten Modulen benötigen, werden aber immer Dienste an übergeordnete Module bereitstellen und übergeordnete Module könnten mehrere Dienste von unterordneten Modulen zusammen kombinieren und benutzen.

Sobald ein Modul identifiziert wird, ergibt sich das Problem, das die Applikation für einen Zweck unterschiedliche verwenden könnte, die eine ähnliche Funktionalität anbieten. Wie könnte man unterschiedliche Implementierungen in der Software Architektur unterstützen? (Bild 3 in der Bildergalerie)

Die erste Option ist trivial, einfach die Applikation zu ändern um den Modul zu ersetzen. (Bild 4 in der Bildergalerie)

Die Nachteile dabei sind, dass oft sowohl die Programmierungs-Schnittstelle (API) als auch die Implementierung nicht gleich sind. Es besteht die Gefahr, dass in dem Programm während der Änderungen Fehler eingeführt werden.

Eine zweite Option könnte beide Module unterstützen. (Bild 5 in der Bildergalerie) Das ist aber mit mehr Aufwand verbunden, weil die Änderungen an jeder Stelle in der das Modul eingesetzt wird, eingeführt werden müssen. Die Funktionsparameter werden höchstwahrscheinlich unterschiedlich sein und ein Leistungsrückgang ist auf Grund der konditionalen Ausführung der Funktionsaufrufe zu erwarten.

(ID:44296110)