AtmelStudio 7, Ampelplatine mit dem ATmega328/P, C++11 und ich

Diesmal habe ich mir eine ganz besondere Aufgabe gestellt.

Schaffe ich, alle Phasen der Software-Entwicklung von der Spezifikation über Design, Kodierung  einschließlich Test mit einer IDE zu realisieren?

Zusätzlich erlaubt sind Plugins, sowie kleine Extra-Tools die sich mit ein paar Handgriffen bedienen lassen. Strikt verboten sind Textprogramme wie MS-Word und UML-Mal-Tools. Okay, Schmierzettel und Kugelschreiber zählen nicht.

 

Also, los gehts.

Vor mir liegt eine kleine Ampelanlage. Sie besteht aus zwei Ampeln realisiert mittels 6 LEDs. Ein Taster dient als Hauptschalter. Die Ampelanlage beinhaltet einen Arduino UNO – einen Einplatinenrechner. Der Micro ist ein ATmega328/P. In der unteren Darstellung ist die Mini-Anlage zu sehen. NR steht für Nebenrichtung und HR für Hauptrichtung.  Die Schaltung benötigt eine Steuerung – die Ampelsteuerung. Sie wird in C++11 realisiert.

Mini-Ampelanlage

Die funktionalen Anforderungen werden ich in Gherkin-Syntax beschrieben. Dafür habe ich vorab das Plugin specflowC installiert. Mit dieser Beschreibungssprache beschreibt man ein oder mehre Features mittelst textueller und spezifischer UseCases. Spezifisch, da konkrete Eingabewerte, Handlungen und Ergebnisse / Ausgabewerte anzugeben sind. Später werden daraus Tests wie UnitTests teilautomatisiert durch einen Parser generiert.

 

Anforderungen in Gherkin-Syntax

Given: Ein Scenario beginnt mit einem Anfangszustand. When: Eine bestimmte Handlung oder ein bestimmtes Ereignis tritt ein. And : Zusätzliche Handlungen oder Ereignisse. Then: Draus folgt ein Ergebnis. And : Zusätzliche Ergebnisse.

Die Daten sind in einer Tabelle aufgelistet.

Spezifikation in Gherkin-Syntax

 

Software-Design im Quellcode mittels Doxygen und Grapgviz

Und nun zum Software-Design, das recht simpel ist. Der Startpunkt ist die Main-Datei. Die Klasse Ampelanlage abstrahiert die Hardware für die Fachklasse Ampelsteuerung.

Die Klassen werden in der Header-Dateien entworfen. Schnittstellenfunktionen deklariert. Der Quellcode wird in der Doxygen– /Grapgviz-Notation dokumentiert. Daraus generiert das Tool Doxywizard die Design-Dokumentation.

Die Ampelanlagen-zustände werden mittels einer Enum in der Klasse Ampelsteuerung realisiert.

Doxywizard generiert daraus folgende Darstellung.

Darstellung der Zustände in der Doxy-Dokumentation

In der Design-Dokumentation soll der Zustandsautomat grafisch dargestellt werden, deshalb füge ich eine zusätzliche Beschreibung ein.

 

Doxywizard generiert daraus folgendes.

 

Klassendiagramme – welche die Beziehungen zischen den Klassen darstellen – generiert Doxywizard automatisch. Eine zusätzlich Beschreibung ist hier nicht von Nöten.

 

So, das Design ist geschafft. Nun steht die Realisierung der UseCases in C++11-Code an. Ich fange mit der Main an. Zuerst wird die Ampelsteuerung initialisiert. Die Klasse Ampelanlage konfiguriert die entsprechenden Register; die 6 LEDs auf I/O-Ausgabe-Ports legen, den Hauptschalter (Taster) auf einen I/O-Eingabe-Port legen und den Interrupt konfigurieren.

Datei main.cpp:

 

Klasse Ampelanlage:

 

Im run-Betrieb werden die entsprechen Ausgänge gesetzt, das Blinken der gelben Nebeneinrichtungs-LED generiert und der Interrupt verarbeitet.

 

Der Ampelsteuerung-Ablauf ist mittels switch-case realisiert. Die Logik ist gut zu lesen und zu verstehen.

 

Fazit

Die Software-Spezifikation konnte mittels specflowC in der IDE erstellt werden. Das Design erfolgte direkt in den Header-Datein in der Doxygen- und Graphviz-Notation. Ein aktuelles Design-Dokument mittels Doxywizard war schnell zu generieren. Die Funktionalität ist in C++11 realisiert, natürlich in abgespeckter Form, bspw. können keine Objekte zur Laufzeit generiert werden.

Offen

Als nächstes steht der UnitTest an … oh, je testen. 

 

Schreibe einen Kommentar