Embed Size (px)
Citation preview
Verantwortlicher Hochschullehrer : Prof. Dr.-Ing. C. Wietfeld
Version vom : 31 July 2015
Lehrstuhl für Kommunikationsnetze
Prof. Dr.-Ing. Christian Wietfeld
Praktikum
Automatisierter Entwicklungsprozess von Kommunikationssystemen
Redaktion: Dipl.-Ing. Dipl.-Kfm. Ralf Burda
III
Inhaltsverzeichnis
Kurzfassung VII
1 Einleitung 1
1.1 Thema der Fallstudie ................................................................................. 1
1.2 Didaktische Zielsetzung des Praktikums ................................................ 2
1.3 Zeitplanung ................................................................................................ 2
2 Ansätze der automatisierten Entwicklung 3
2.1 Problemfeld „Qualität“ .............................................................................. 3
2.2 Ziel des automatisierten Entwicklungsprozesses .................................. 4
2.3 Typische Werkzeuge ................................................................................. 4
2.3.1 Modellierung ..................................................................................... 4
2.3.2 Test und Verifikation ......................................................................... 5
3 Die Arbeitsumgebung 7
3.1 Verwendete Werkzeuge ............................................................................. 7
3.1.1 Die Eclipse Workbench und deren Installation.................................. 7
3.1.2 Yakindu Statechart Tools ................................................................ 11
3.1.3 TTWorkbench ................................................................................. 12
3.1.4 AVR Tools in der Übersicht............................................................. 12
3.2 Die Hardwareplattform ............................................................................ 12
3.2.1 Der Prozessor ................................................................................. 12
3.2.2 Die I/O Schnittstellen ...................................................................... 13
3.2.3 Die Funkschnittstelle ....................................................................... 14
3.2.4 Kommunikation zu einem PC.......................................................... 14
3.3 Das Programmiergerät ............................................................................ 14
3.3.1 Handhabung ................................................................................... 14
3.3.2 Einbindung in die Werkzeugkette ................................................... 15
4 Das Anforderungsdokument 17
4.1 Allgemeines.............................................................................................. 17
4.2 Formlose Beschreibung des Systemverhaltens ................................... 17
4.3 Formale Struktur eines Anforderungsdokuments ................................ 18
IV Kurzfassung
5 Arbeitsablauf der automatisierten Entwicklung 21
5.1 Definition von Anwendungsfällen (Use-Cases) .................................... 21
5.1.1 Nutzung von Anwendungsfällen ..................................................... 21
5.1.2 Die Use–Case Notation .................................................................. 21
5.1.3 Alternative Methoden zur Definition (z.B. Mindmaps) ..................... 23
5.2 Definition der geforderten Systemkomponenten .................................. 24
5.2.1 Rollen von physischen Komponenten ............................................. 24
5.2.2 Aufgaben von Softwarekomponenten ............................................. 24
5.3 Definition der Wirkungszusammenhänge ............................................. 25
5.3.1 Inter-Komponenten Kommunikation ............................................... 25
5.3.2 Beschreibung von Testfällen........................................................... 26
5.4 Eingabe der Zustandsautomaten (State-Charts) ................................... 28
5.4.1 UML State–Charts vs. SDL ............................................................. 28
5.4.2 Eingabe eines State–Charts ........................................................... 30
5.4.3 Restriktionen bei der Eingabe ......................................................... 31
5.5 Simulation des Systemverhaltens .......................................................... 32
5.5.1 Planung der Simulation ................................................................... 32
5.5.2 Durchführung der Simulation .......................................................... 33
5.5.3 Interpretation der Ergebnisse.......................................................... 34
5.6 Erzeugung von ausführbarem Quelltext ................................................ 34
5.6.1 Codegenerierung aus abstraktem Modell ....................................... 34
5.6.2 Verstehen des erzeugten ‚C‘-Codes ............................................... 36
5.6.3 Funktion der Steuerungskonstrukte ................................................ 36
5.7 Einbettung in die Systemumgebung ...................................................... 37
5.7.1 Erstellung eines Software-Rahmens für die Ausführung ................ 37
5.7.2 Abbildung (Codierung) von Variablen auf physikalische I/O
Komponenten ................................................................................. 37
5.7.3 Vom Code-Review zum Integrationstest ......................................... 37
5.7.4 Definition von Testschnittstellen ..................................................... 38
5.8 Implementierung von Tests in TTCN-3 .................................................. 39
5.8.1 Erfassung von Testfällen ................................................................ 39
5.8.2 Bewertung der Ergebnisse (verdicts) .............................................. 40
5.8.3 Aussagekraft der Ergebnisse .......................................................... 41
5.9 Programmierung und Test auf dem Zielsystem .................................... 42
5.9.1 Verwendung des Programmiergerätes und Verkabelung ............... 42
5.9.2 Laden und Debuggen der erzeugten Software ............................... 43
V
5.10 Verifikation, Validierung und Abschlussdokumentation ..................... 44
6 Bedingungen für eine erfolgreiche Teilnahme 45
7 Praktikumsaufgaben 47
7.1 Allgemeines.............................................................................................. 47
7.2 Implementierung eines einfachen UML State–Charts .......................... 47
7.2.1 Beispiel: Etablierung des Funknetzes (1,5h)................................... 47
7.2.2 Beispiel: Modellierung des Anmeldeprozesses (2,5h) .................... 47
7.3 Integration mit der Hardwareplattform .................................................. 48
7.3.1 Arbeiten mit der Quellcodeverwaltung (0,5h) .................................. 48
7.3.2 Verwendung der Team–Funktionen (1h) ........................................ 48
7.3.3 Aufbau einer Ausführungsumgebung auf der Zielplattform (2h) ..... 48
7.4 Einführung in die Fallstudie.................................................................... 49
7.4.1 Erstellung einer Demoapplikation (1,5h) ......................................... 49
7.4.2 Verbesserung des Beispiel–State–Charts (1h) ............................... 49
7.4.3 Pflege des Anforderungsdokuments (0,5h) .................................... 49
7.5 Lokale Tests auf der Hardwareplattform ............................................... 50
7.5.1 Erstellung, Programmieren und Debugging (2h) ............................. 50
7.5.2 Austausch des manuellen Codes gegen ein State–Chart (1h) ....... 50
7.5.3 Einbindung der Demoapplikation in den Hardwarekontext (1h) ...... 50
7.6 Integration des Funknetzes (I) ................................................................ 50
7.6.1 Umsetzung einer Beispielapplikation (3h) ....................................... 50
7.6.2 Integration von Applikation und Funkschnittstelle (3h) .................... 51
7.7 Integration des Funknetzes (II) ............................................................... 51
7.7.1 Tests zwischen 2 Komponenten (3h) .............................................. 51
7.7.2 Integration zwischen Teams (3h) .................................................... 51
7.8 Erstellung von Testszenarien in TTCN-3 ............................................... 52
7.8.1 Einbindung der Demo–Applikation in den Test (2h) ........................ 52
7.8.2 Einbindung der Hardware in die Testumgebung (1,5h) .................. 52
7.8.3 Grundlagen des automatisierten Testens (1,5h) ............................. 52
7.9 Qualifikation und Freigabe des Ergebnisses ........................................ 52
7.9.1 Einbindung der Hardware in den Testablauf (2h) ........................... 52
7.9.2 Abschlussdokumentation (2h)......................................................... 53
VII
Kurzfassung
Das Praktikum „Automatisierter Entwicklungsprozess von Kommunikationssys-
temen“ stellt an Hand der Fallstudie „Funkbasiertes Sensornetzwerk“ den
Arbeitsablauf von der ersten Idee über eine modellbasierte Beschreibung bis zur
lauffähigen Implementierung einer Lösung auf einer bestehenden
Hardwareplattform dar.
Bei der Durchführung des Praktikums wechseln die Einführung von Werkzeugen
und Arbeitstechniken im Plenum sowie die Erarbeitung von Ergebnissen in
Kleingruppen einander ab. Das Praktikum beginnt mit der Einführung in die
verwendete Werkzeugkette und ersten Arbeitsschritten bei der Erstellung der
Projektumgebung sowie der Zusammenarbeit im Team. Es folgen eine Einführung
in die Erstellung und Verwaltung der Projektdokumente und praktische Versuche an
der Zielplattform.
Im Anschluss an diese Einführungsphase beginnt die Strukturierung der Lösung mit
der Erstellung von Mindmaps und UML Anwendungsfalldiagrammen. Hieraus
werden dann im Weiteren Statecharts sowie Testfälle definiert, deren Verifikation
zunächst durch Simulationen erfolgt.
Nach erfolgreichem Abschluss dieses Projektschritts wird dann die formale
Beschreibung in lauffähigen Code transformiert. Diese Transformation wird
automatisiert durch die Entwicklungsumgebung durchgeführt.
Die nächste Aufgabe ist dann die Einbettung der erstellten Lösung in den Rahmen
der Zielplattform. Diese Phase schließt mit der Programmierung der Netzknoten und
einem ersten Funktionstest ab.
Das Praktikum endet mit einer Verifikation und einer einfachen Validierung der zu
Beginn im Design festgelegten Funktionalitäten und der Erstellung eines
Abschlussdokuments.
1
1 Einleitung
1.1 Thema der Fallstudie
Im Praktikum wird die Aufgabe der funkbasierten Kommunikation von einem (oder
mehreren) mobilen Sensoren zu einer zentralen Sammelstelle mit Methoden der
modellgetriebenen Systementwicklung gelöst. Die mobilen Knoten sollen dabei
Umwelteinflüsse (z.B. einen Tastendruck) per Funkkommunikation an die zentrale
Station melden. Letztere überträgt dann diese Daten (per USB) an einen PC. Dieser
wiederum stellt die Ereignisse und den Zeitpunkt ihres Auftretens in einer minimalen
Oberfläche dar.
Abbildung 1: Grundkonzept des Fallstudie
In dieser einfachen Konfiguration können bereits wesentliche Elemente einer
mobilen Kommunikation nachvollzogen werden, wie z.B.
- Rollenverhalten der Funkteilnehmer
- Identifizierung des mobilen Teilnehmers
- Überwachung bekannter und aktiver Kommunikationsverbindungen
- Behandlung von Übertragungsfehlern
Die operativen Aufgaben des Praktikums führen von ersten Designüberlegungen bis
hin zu einer vollständigen Lösung der gestellten Problematik und umfassen neben
der funktionalen Umsetzung mit Hilfe einer weitgehend automatisierten
Werkzeugkette auch Aspekte der Dokumentation und Verifikation der erarbeiteten
Lösungen.
Im Rahmen des Praktikums wird diese Grundkonfiguration zu einer kompletten
Ampelsteuerung mit Fußgängerampel erweitert, deren Aufbau in Abbildung 2
skizziert ist.
USB
Funkkanal2,4GHz
2 Einleitung
Abbildung 2: Vollständiger Aufbau der Fallstudie
1.2 Didaktische Zielsetzung des Praktikums
Es werden Wissen und Fähigkeiten vermittelt, wie automatisierte Umgebungen die
Qualität des Softwareentwicklungsprozesses für Kommunikationssysteme positiv
beeinflussen und die Arbeitsabläufe effizient gestalten. In diesem Kontext werden
auch Methoden und Kompetenzen in der Teamarbeit vermittelt.
Operativ werden diese Fähigkeiten bei der Umsetzung des Systems der Fallstudie
trainiert und die notwendigen, einzelnen Arbeitsschritte bis zur erfolgreichen
Umsetzung einer Lösung erprobt.
Alle erfolgreichen Teilnehmer sollen am Ende des Praktikums Fähigkeiten
entwickelt haben die folgenden Aufgaben zu übernehmen:
Identifikation von Teilproblemen bei der Lösung einer gestellten
Entwicklungsaufgabe.
Bewertung von Werkzeugen im Hinblick auf die Nutzbarkeit für bestimmte
Problemklassen.
Spezifikation von Arbeitsabläufen durch Wahl geeigneter Methoden.
Erstellung von Anforderungsdokumenten.
Erstellung von einfachen Prüfplänen.
1.3 Zeitplanung
Das Praktikum besteht aus insgesamt 15 Sitzungen zu je 3 (Zeit-)Stunden. Eine
weitere Sitzung kann bei Bedarf, z.B. zur Vervollständigung von Dokumenten, in
Absprache mit der Praktikumsleitung als Ersatz für das notwendige Eigenstudium,
eingerichtet werden.
Die einzelnen Sitzungen werden wechselnd für die Einführung in Werkzeuge und
Arbeitstechniken und für die Durchführung praktischer Tätigkeiten der Studierenden
genutzt.
Die Inhalte der Sitzungen bauen aufeinander auf, so dass eine kontinuierliche
Mitarbeit der Studierenden notwendig ist.
USB
Funkkanal2,4GHz
3
2 Ansätze der automatisierten Entwicklung
2.1 Problemfeld „Qualität“
Eines der wesentlichen Ziele bei der Entwicklung jeglichen Produkts ist die
Erreichung einer hohen Produktqualität.
Qualität (ist die) Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder
einer Tätigkeit, die sich auf deren Eignung zur Erfüllung gegebener Erfordernisse
bezieht [DIN 55350, Teil 11]
Da Eigenschaften und Merkmale nicht nur von der Intension des Herstellers
sondern auch wesentlich von der Qualität des gesamten Entwicklungs– und
Fertigungsprozesses abhängen, sind Fehlerquellen in allen Phasen eines
Produktlebenszyklus nach Möglichkeit auszuschließen.
Bei sehr komplexen Systemen wie Kommunikationssystemen, die aus einer Vielzahl
miteinander interagierender Komponenten bestehen und die typisch verteilt durch
große Gruppen von Mitarbeitern entwickelt werden, stellt bereits der korrekte
Austausch und das Verständnis von Planungsdokumenten eine Herausforderung
dar. (Wer hat wann, was und in welcher Version getan?)
Die Qualitätsdefinition nach ISO 9216 spannt ein weites Feld der Begriffsdefinition,
die sich beispielsweise wie folgt strukturieren lässt:
Qualität bzw. deren Wahrnehmung wird z.B. beeinflusst durch
Funktionalität
o Angemessenheit
o Sicherheit
o Genauigkeit
o Interoperabilität
o Konformität zu Standards
Zuverlässigkeit
o Reife
o Fehlertoleranz
o Wiederherstellbarkeit
Benutzbarkeit
o Verständlichkeit
o Erlernbarkeit
o Bedienbarkeit
Effizienz
o Zeitverhalten
o Verbrauchsverhalten
o Kosten
Änderbarkeit
o Analysierbarkeit
o Modifizierbarkeit
o Stabilität
o Prüfbarkeit
Übertragbarkeit
o Anpassbarkeit
o Installierbarkeit
o Austauschbarkeit
o Konformität zu Standards
Es wird allgemein angenommen, dass die zuvor genannten Schlagwörter sich mit
bewertbaren Attributen eines Produkts und seines Fertigungszyklus assoziieren
lassen und Qualität so messbar wird.
Gleichzeitig erscheint offensichtlich, dass die Bewertung z.B. der „Verständlichkeit“
sicher individuell vom Anwender und dessen Erwartungen abhängt. Die Abbildung 3
skizziert hier die Zusammenhänge für den Bereich der Softwareentwicklung.
4
Abbildung 3: Einfluss auf die Qualität (nach Braune, TU Braunschweig)
Dabei stellt die „Entwicklung“ den zeitlichen Verlauf von der Idee bis zur
Realisierung dar. „Verifikation“ fragt dabei immer „haben wir es richtig gemacht?“,
d.h. entspricht ein lauffähiges Programm nachweisbar den Vorgaben aus dem
Anforderungsdokument. „Validierung“ hingegen fragt „haben wir das Richtige
gemacht?“, sind also die Erwartungen des Anwenders erfüllt worden.
2.2 Ziel des automatisierten Entwicklungsprozesses
Die Automation von Prozessen hat allgemein (z.B. in der Automobilindustrie) den
Anspruch, ein bestimmtes Qualitätsniveau reproduzierbar lieferbar zu machen. In
Abbildung 3 ist veranschaulicht, dass durch den Prozess der Entwicklung eine
Transformation von Dokumenten erfolgt. Letztlich ist ein Anforderungsdokument
ebenso ein Text wie eine (maschinenlesbare) Modellbeschreibung und am Ende der
Wirkungskette der Programmcode (Quelltext).
Die Arbeitsaufgabe der Softwareentwicklung lässt sich also als eine „Übersetzung“
von abstrakten Beschreibungen in eine konkrete Implementierung verstehen.
In diesem Praktikum soll nun dargestellt werden, mit welchen Methoden dieser
Transformationsprozess reproduzierbar, verifizierbar, validierbar, effizient und im
Ergebnis für den Anwender verständlich gestaltet werden kann.
Es werden daher Softwarewerkzeuge eingesetzt, die den Anteil des manuell
generierten Codes im Gesamtsystem minimieren und Komplexität durch grafische
Methoden (Modelleingabe) handhabbar machen.
2.3 Typische Werkzeuge
2.3.1 Modellierung
Für die grafische Modellierung auf dem Weg vom Anforderungsdokument hat in den
letzten Jahren die Unified–Modeling–Language (UML) zunehmend an Bedeutung
gewonnen. Die Modellierung der Funktionalität für die in diesem Praktikum steht
Qualitätsempfinden(Benutzererwartungen)
Anforderungsdokument
ProgrammCodeModelle
Entwicklung
Verifikation Verifikation
Val
idie
run
g
Typische Werkzeuge 5
dabei neben der Erfassung der Beziehung zwischen System und Anwender in
Vordergrund.
UML selbst bietet mit sieben Struktur– und sieben Verhaltensdiagrammen eine
Vielzahl von standardisierten Diagrammtypen an. Diese Diagramme, z.B. unter
http://www.omg.org/spec/UML/2.3/ spezifiziert, sind jedoch nur zu einem kleinen
Teil dazu geeignet, als Teil einer automatisierten Werkzeugkette für einen konkreten
Anwendungsfall zu dienen. Dies sind insbesondere:
Das Klassendiagramm:
Dieses Diagramm beschreibt die statische Struktur einer Software. Darunter
fallen Hierarchien von Klassen und Abhängigkeiten von Datentypen
untereinander.
Klassendiagramme stellen somit keine Funktionalität bereit, liefern aber eine
Übersicht über implementierte Funktionen und die Struktur der Software.
Die Semantik der Klassendiagramme lässt (bei korrekter Wahl der
Nomenklatur) eine direkte Erzeugung von Quelltext in unterschiedliche
Zielsprachen zu.
Das State–Chart Diagramm:
Dieses Diagramm beschreibt das Verhalten eines Softwareobjekts in Form
eines so genannten endlichen Automaten. (Finite–State–Machine (FSM)).
Die Semantik des Diagramms erlaubt es dann, direkt eine Ablaufsteuerung in
einer Zielsprache zu erzeugen. Das UML State–Chart ist in der in diesem
Praktikum verwendeten Form eine Weiterentwicklung der so genannten
SDL–Charts (System Description Language).
Grundsätzlich ist es jedoch in UML zulässig, Elemente und Zusammenhänge auch
in englischer Sprache, d.h. in einer natürlichen Sprache, zu notieren. Damit scheidet
in vielen Fällen die automatisierte Nutzung des Weges „Entwicklung“ aus Abbildung
3 aus. Durch konsistente Namensgebung kann allerdings ein Kontext zwischen
unterschiedlichen Diagrammen etabliert werden, so dass geeignete Werkzeuge
sehr wohl Fragen der Verifikation wie:
Gibt es zu jedem angeforderten Element auch eine Klasse?
Ist für jeden Anwendungsfall eine Verhaltensbeschreibung des Systems
implementiert?
beantworten können.
Darüber hinaus bietet UML eben durch die „lesbare“ Notation in vielen Fällen die
geforderte Möglichkeit der Validierung mit dem Anwender.
2.3.2 Test und Verifikation
In Kommunikationssystemen, z.B. in Mobilfunksystemen, liegt eine der
Schwierigkeiten bei der Verifikation in der schier unüberschaubaren Menge von
Ereignissen, Zeitabläufen und Systemvariablen. Der Foliensatz https://www.tu-
braunschweig.de/Medien-DB/isf/sse/vl8_testen.pdf gibt eine gute Übersicht über
die generelle Testproblematik.
Unter der Prämisse, dass eine Entwicklung auch in adäquater Zeit fertig zu stellen
ist, erscheint offensichtlich, dass ein vollständiger Test eines Systems nie möglich
sein wird (dies lässt sich auch formal nachweisen). Jedoch lassen sich häufig die
6
definierten Anwendungsfälle so in Aktivitätssequenzen abbilden, das zumindest für
die geplante Anwendung eine korrekte Funktion geprüft werden kann.
Um die Beschreibung dieser Tests zu standardisieren und zu automatisieren, wird in
diesem Praktikum ein weiteres professionelles Werkzeug, die TTWorkbench,
verwendet. Hierbei werden Tests in der so genannten „Test and Testing Control
Notation“ (TTCN-3) beschrieben und schließlich zur Ausführung gebracht. Diese
Methode erlaubt es eine Vielzahl von reproduzierbaren Tests in kurzer Zeit
automatisch ablaufen zu lassen und die Resultate der Tests, ebenfalls
standardisiert, zu bewerten.
TTCN-3 stammt originär aus dem Umfeld der Kommunikationssysteme und wird
häufig für Integrationstests und Systemtests verwendet. Extensive, manuelle Tests,
wie sie Ende der 80’er Jahre des 20. Jahrhunderts noch durchgeführt wurden,
werden damit abgelöst.
TTCN-3 und die entsprechenden Werkzeuge beantworten jedoch nicht die Frage,
ob ein Test auch zielführend, sinnvoll, effizient oder überhaupt mit einem
Anwendungsfall in Deckung ist.
7
3 Die Arbeitsumgebung
3.1 Verwendete Werkzeuge
3.1.1 Die Eclipse Workbench und deren Installation
Die Bearbeitung praktisch aller Aufgaben dieses Praktikums wird im „Eclipse“
Framework durchgeführt. Diese so genannte „Workbench“ erlaubt die Integration
vielseitiger Werkzeuge in einen gemeinsamen Arbeitsablauf. Die wesentlichen, hier
verwendeten Komponenten, setzen sich aus dem Modeling Framework, einem UML
Eingabe und Simulationswerkzeug (Yakindu), der C/C++ Programmierumgebung
und spezifischen Werkzeugen für die Programmierung der Zielhardware
zusammen.
Diese Arbeitsumgebung ist kostenfrei unter EPL (Eclipse Public License) erhältlich
und kann für das im Praktikum vorgesehene Eigenstudium wie folgt installiert
werden.
1) Download des Eclipse Juno(4.2) Modeling frameworks
Die Installation erfolgt durch einfaches Entpacken an beliebiger Stelle auf
Ihrer Festplatte.
2) Wechseln Sie in den entsprechenden Ordner und entpacken Sie das Archiv
8 Die Arbeitsumgebung
3) Starten Sie Eclipse durch Doppelklick.
Achten Sie bei der Auswahl der Workspace im Retina Pool darauf, dass Sie
nicht die Voreinstellung akzeptieren, sondern den Arbeitsbereich mit
„R:\workspace“ initialisieren. Stellen Sie sicher, dass es sich um einen neuen
Arbeitsbereich handelt.
4) Sie sehen nun folgendes Fenster.
5) Installieren Sie nun die C/C++ Programmierumgebung, in dem Sie zunächst
den Menupunkt „Help->Install New Software“ auswählen
Verwendete Werkzeuge 9
6) Sie erhalten einen Auswahldialog, in dem Sie unter „Work with“ den Eintrag
http://download.eclipse.org/releases/juno per dropdown auswählen. Öffen
Sie dann in der Auswahl den Knoten „Programming Languages“ und
selektieren Sie die gezeigten 5 Einträge, so dass hier (und nur hier) jeweils
ein Haken gesetzt ist.
Stellen Sie sicher, dass weiter unten auch ein Haken bei „show only latest
version of available software“ gesetzt ist.
Danach bestätigen Sie Ihre Auswahl durch klicken auf „Next“. Nach dem
zweiten „Next“ werden Sie zum Akzeptieren der EPL (Eclipse Public License)
aufgefordert. Bestätigen Sie dies und klicken Sie dann auf „Finish“. Nun wird
die C/C++ Programmierumgebung installiert.
Abschließend startet Eclipse auf Nachfrage neu.
10 Die Arbeitsumgebung
7) Wiederholen Sie den Installationsschritt und verwenden Sie dieses Mal
http://updates.yakindu.com/juno/milestones als Repository für die
Installation. Selektieren Sie alle Komponenten und bestätigen Sie alle
weiteren Anfragen positiv. Am Ende des Installationsvorgangs wird Eclipse
einen Neustart verlangen.
8) Testen Sie nun Ihre Installation, in dem Sie über File->New das vorgefertigte
Beispiel für ein Statechart erzeugen.
9) In einem weiteren Installationslauf wird nun die Werkzeugkette für den
Mikrocontroller, die so genannte AVR Toolchain, installiert. Gehen Sie
erneut wie in den vorangegangenen Schritten vor und wählen Sie http://avr-
eclipse.sourceforge.net/updatesite als Quelle aus und installieren Sie alles
wie gefordert.
Bitte beachten Sie, dass Sie nach der Installation zunächst keine direkten
Veränderungen an den Eclipse Menus feststellen werden. Erst beim
Versuch, über den Menupunkt „File->New->Others“ ein neues C/C++ Projekt
anzulegen, finden Sie in einer Auswahlbox die entsprechenden Projekttypen.
In diesem Praktikum werden wir den Projekttyp „AVR Cross Target
Application verwenden.“
Verwendete Werkzeuge 11
Nach dem Erstellen eines entsprechenden Projekts erscheint für den
umgebenden Arbeitsbereich im Hauptmenu von Eclipse nun ein Eintrag
„AVR“.
10) Abschließend benötigen Sie noch ein Werkzeug, um in Ihrem Team die
verwendeten Dokumenten zwischen allen Teilnehmern zu synchronisieren.
Hierzu installieren Sie ein entsprechendes Revisionierungswerkzeug
von http://subclipse.tigris.org/update_1.8.x. Mit dessen Hilfe werden
während des Praktikums die entstandenen Originaldokumente gesichert und
ihre jeweilige Historie gespeichert.
Die Installation ist nun abgeschlossen. Während der Durchführung des Praktikums
werden Sie mit der Erstellung von weiteren, notwendigen Projekten und deren
Handhabung in unterschiedlichen Arbeitsschritten vertraut gemacht.
3.1.2 Yakindu Statechart Tools
Die Yakindu Statechart Tools lassen die Eingabe einer Untermenge der Unified
Modeling Language (UML) zu, und zwar die so genannten State Charts. Neben den
so genannten Klassendiagrammen (Class Diagrams) sind die Statecharts
grundsätzlich die einzigen UML Diagrammtypen, die sich direkt in Quelltext anderer
Programmiersprachen umsetzten lassen.
Statecharts stellen in dieser Hinsicht ein modernes Analogon zu der schon länger
bekannten Sprache SDL (System Description Langugage) dar und erlauben die
Formulierung so genannter endlicher Automaten (oder Finite State Machines,
FSMs). In der vorliegenden Version ist es möglich, die definierten Diagramme bzw.
die durch sie modellierte Funktionalität direkt in Eclipse zu simulieren.
12 Die Arbeitsumgebung
3.1.3 TTWorkbench
Die TTWorkbench ist ein professionelles und anerkanntes Werkzeug zur Definition
von Testfällen für Softwareartefakte. Dies schließt die Erstellung, Dokumentation
und die Ausführung von Testfällen ein.
TTWorkbench benötigt eine aktive Softwarelizenz und ist auf den
Arbeitsumgebungen im Praktikumspool vorinstalliert. Da keine public license für die
Nutzung im Eigenstudium zur Verfügung steht, wird auf Installation, Funktion und
Bedienung an dieser Stelle nicht eingegangen.
3.1.4 AVR Tools in der Übersicht
Die AVR Tools stellen die Entwicklungsumgebung für die Zielplattform bereit. Hierzu
gehören im Wesentlichen die Komponenten „Compiler“ und „Linker“. Ersterer
erzeugt im Praktikum aus den (zum großen Teil automatisch erzeigten Quelltexten)
einen für die Ziel-MCU ausführbaren Binärcode, während der Linker den Binärcode
der unterschiedlichen Module (Quelldateien) verbindet und Abhängigkeiten
zwischen diesen auflöst. Am Ende des Linker-Laufs werden dann den Elementen
dieses Objekt-Codes feste Speicheradressen zugewiesen und eine für das
Programmierwerkzeug lesbare Ausgabedatei erstellt.
ACHTUNG: Versuchen Sie nie, diese Datei auf Ihrem PC auszuführen. In der Regel
ist das Format zwar für Ihr Betriebssystem unbekannt und wird daher abgewiesen,
aber sollte sich zufällig eine solche Datei laden lassen, so ist die Reaktion Ihres PC
unvorhersehbar.
3.2 Die Hardwareplattform
Im Rahmen dieses Praktikums werden Entwicklungssysteme des Typs
„deRFdevelopmentKit mega128“ verwendet. Diese bieten neben dem
Mikrocontroller (MCU) Modulen auch ein Adapter-Board, mit dem über Taster und
LED’s einfacher Zugang zu den Ein- und Ausgabeschnittstellen des verwendeten
Mikrocontrollers geschaffen ist.
Des Weiteren werden die Baugruppen per USB–Schnittstelle oder per Batterie mit
Strom versorgt. Die USB Schnittstelle kann auch gleichzeitig zur Kommunikation
eines Moduls mit dem angeschlossenen PC verwendet werden. Zu jeder
Arbeitsgruppe im Praktikum gehören
1) Ein Entwicklungskit incl. Kabel.
2) Ein USB-Steckernetzteil.
3) 1 Programmiergerät (siehe Abschnitt 3.3 auf Seite 14).
3.2.1 Der Prozessor
In diesem Praktikum findet ein 8-Bit Mikrocontroller des Typs ATMega128RFA1
Verwendung. Dieser Prozessor ist in der AVR RISC Architektur der Fa. Atmel
ausgeführt und bietet on Chip die Anbindung an eine Funkschnittstelle nach dem
Standard IEEE 802.15.4. Dieser wird häufig, wenn auch formal so nicht korrekt, mit
dem Namen „ZigBee“ assoziiert.
Die Hardwareplattform 13
Der Prozessor bzw. der vorhandene Flash Programmspeicher von 128kByte ist
über ein so genannten JTAG Interface programmierbar. Die für dieses Praktikum
relevanten Kenndaten sind:
Flash Speicher: 128kByte
RAM: 16kByte
Taktfrequenz: 16 MHz
Digitale Ein/Ausgangsleitungen: 32
Ein Datenblatt für diesen Mikrocontroller findet sich im Internet unter
www.atmel.com/Images/doc8266.pdf.
3.2.2 Die I/O Schnittstellen
Im Entwicklungssystem stehen als direkte Ein- und Ausgabefunktionen 1 Taster und
insgesamt 5 LED’s zur Verfügung. Diese werden durch das so genannte Sensor-
Terminal-Board (STB) und das Radic Controller Board (RCB) zusammengeführt,
wobei das STB auch die USB Schnittstelle enthält.
Abbildung 4: Entwicklungsboard mit Ein- und Ausgabe
Weiter Komponenten können über die Klemmleisten des STB (in Abbildung 4 am
unteren Rand) angeschlossen werden. Dies ist im Rahmen des Praktikums jedoch
nicht vorgesehen.
Von den pro Gruppe vorhandenen Einheiten wird jeweils eine direkt per USB an den
PC angeschlossen und dient so als zentrale Sammelstelle für die von der mobilen
Station eingehenden Daten.
ACHTUNG: Durch die Verwendung als Kommunikationsschnittstelle werden einige
der I/O Ports blockiert und stehen für eine freie Verwendung nicht mehr zur
Verfügung.
LED‘s ( 1 - 3 )
LED‘s ( 4 & 5)
Taster
14 Die Arbeitsumgebung
3.2.3 Die Funkschnittstelle
Die Funkschnittstelle arbeiten im 2.4GHz ISM Band und folgt in der
Implementierung der IEEE 802.15.4 Norm. Für die Nutzung und Programmierung
wird hier ein vorgefertigter Protokollstapel verwendet, wie er von Hersteller der MCU
kostenlos unter http://www.atmel.com/tools/IEEE802_15_4MAC.aspx angeboten
wird. Dieser Protokollstapel bietet über eine einfache Programmierschnittstelle die
Möglichkeit, Daten zwischen unterschiedlichen Stationen über den Funkkanal zu
übertragen.
Die maximale Datenrate des genannten Funkstandards beträgt 256kBit/s, jedoch
sind davon auf Grund des Overheads, des konkurrenzbasierten Zugriffs und
anderer Rahmenbedingungen im besten Fall ca. 128kBit/s nutzbar. Für die
Fallstudie dieses Praktikums spielt diese Beschränkung jedoch keine Rolle.
3.2.4 Kommunikation zu einem PC
Gegenüber dem PC stellt sich das STB als serielle Schnittstelle dar. Auf diese
Weise ist es relativ einfach, an dieser Stelle Textnachrichten, aber auch andere
Information von proprietärem Format, auszutauschen. Auf der PC Umgebung sind
entsprechende Treiber vorinstalliert, um aus der Eclipse Umgebung heraus direkt
mit einer seriellen Schnittstelle zu kommunizieren und diese in der im Praktikum
erstellten Softwareteilen zu verwenden.
3.3 Das Programmiergerät
3.3.1 Handhabung
Als Programmiergerät findet ein AVR JTAG ICE MkII Verwendung. Es stellt die
Verbindung zwischen PC (mit Entwicklungsumgebung) und der Zielhartware her.
Neben der Programmierung dient dieses Gerät auch dem Debugging auf der
Zielplattform, in dem es das Setzen von Unterbrechungspunkten sowie das
Auslesen und Setzen von Registern und Speicherbereichen der MCU ermöglicht.
Abbildung 5 Das Programmiergerät JTAG Ice MkII
Dieses Gerät wird über eine USB Schnittstelle mit dem Programmier- und Steuer
PC verbunden. Es wird von hier aus mit Energie versorgt und verwendet die USB
Das Programmiergerät 15
Schnittstelle gleichzeitig auch als Kommunikationsmedium für den
Programmiervorgang und das Debuggen.
Wichtig ist dabei das folgende Vorgehen:
1) Verbinden Sie zunächst die USB Schnittstelle des Programmiergeräts mit
dem PC.
2) Stellen Sie nun sicher, dass die Spannungsversorgung der Zielplattform
ausgeschaltet ist!
3) Verbinden Sie nun den 10 poligen JTAG Stecker (im Bild am Ende der
flexiblen Flachleitung) gemäß des Handbuchs der Zielplattform mit dem
Entwicklungsboard.
4) Schalten Sie nun die Versorgungsspannung des Zielsystems ein (z.B. durch
Einstecken einer USB Verbindung).
Jetzt sollte eine Verbindung zwischen dem PC, dem Programmiergerät und der
Zielplattform existieren. Bei der Durchführung des Praktikums werden Sie lernen,
die grundsätzliche Funktion dieser Verbindung vor dem eigentlichen
Programmiervorgang zu testen.
3.3.2 Einbindung in die Werkzeugkette
Das Programmiergerät bedarf neben den bereits unter 3.1.1 ab Seite 7
beschriebenen und installierten Softwarekomponenten keiner gesonderten
Betriebssoftware. Ist ein „AVR Cross Target“ Projekt aktiv, so erscheint in der
Werkzeugleiste von Eclipse ein Programmierknopf.
Diese Funktion in Eclipse wird in diesem Praktikum zu zwei Zwecken genutzt:
a) Kontrolle, ob ein Projekt tatsächlich für die Zielhardware kompatiblen Code
erzeugt.
b) Management der Projektinhalte
Die eigentliche Programmierung und das Debugging der Hardware wird außerhalb
von Eclipse unter einer herstellerspezifischen Applikation, dem Atmel Studio,
Version 6.0 vorgenommen. Diese Umgebung ist in das Framework des Microsoft
Visual Studio eingebettet. Ein so genannte „Solution“ wird einfach wie folgt
innerhalb des Eclipse workspaces angelegt. Diese Beschreibung geht davon aus,
dass Sie bereits in Ihrem Workspace ein AVR Cross Target C Projekt angelegt
haben, das den Namen „deRF-AEK“ trägt.
Für die Nutzung Ihres Netzlaufwerks im Retina Pool ist zu beachten, dass Sie
bei der Auswahl Ihres Arbeitsbereiches den Laufwerksbuchstaben „R:“
voranstellen sollten. Andernfalls gibt es Problem mit der Auflösung von
Pfaden im weiteren Verlauf.
16 Die Arbeitsumgebung
Klicken Sie im Startbildschirm des
Werkzeugs auf „New Project“
Wählen Sie nun den Projekttype „GCC C
Executable Project“ aus.
Selektieren Sie Ihren Eclipse Workspace als
Zielordner.
Geben Sie dem Projekt einen Namen und
beachten Sie, den Haken bei „Verzeichnis
für Lösung erstellen“ zu setzen.
Wählen Sie nun im nächsten Dialog die CPU
ATmega128RFA1 aus uns bestätigen Sie
mit „OK“.
ACHTUNG: Löschen Sie nun die automatisch
erstellte Datei „deRF-AEK.c“ sowohl aus dem
Projekt als auch von der Festplatte.
Modifizieren Sie nun die Projektoptionen unter „Projekt–>Eigenschaften“ (oder per
Alt-F7“. Setzen sie einen Haken bei der Option „use external makefile“ und
Navigieren Sie mit dem „Browse“ Knopf zu „./workspace/deRF-
AEK/Debug/makefile“. Bestätigen Sie die Auswahl mit „Öffnen“.
Damit sind die Einstellungen komplett und Sie können den Code für das Zielsystem
durch Drücken der Taste „F7“ erzeugen.
Ist die Übersetzung erfolgreich, so kann über die Debug-Funktionen der Oberfläche
der Code auf die Ziel-MCU geladen und dort ausgeführt werden.
Hinweis: Im Vergleich zu älteren Versionen des Atmel Studios hat diese Version
den Vorteil, die CPU zwischen mehreren Debug-Läufen nur dann neu zu
programmieren, wenn eine Änderung der Quelltexte gefunden wurde.
Das eigentliche Debugging kann nun mit den von Visual Studio bekannten
Tastenkombinationen begonnen werden. Nach dem Start der Software verharrt der
Cursor zunächst auf der ersten Zeile der „main“ Funktion.
Unter den Debug-Fenstern findet sich zusätzlich eine Möglichkeit, die register und
Ein–/Ausgabeleitungen der MCU direkt anzuzeigen.
Auf die Nutzung dieser Optionen wird während der Praktikumsdurchführung näher
eingegangen.
17
4 Das Anforderungsdokument
4.1 Allgemeines
Ein Anforderungsdokument sollte am Anfang jeder Entwicklung stehen. Dies gilt
ebenso für technische Systeme wie auch für viele andere Lebensbereiche. Ein
Beispiel:
Sie möchten ein Haus bauen. Die Intuition und die Lebenserfahrung lehrt
uns, dass dies ein komplexer, länger andauernder Prozess ist, der einer
guten Vorplanung bedarf. Die Größe des Hauses wird sich nach Ihren
Wünschen und auch nach Ihren finanziellen Möglichkeiten richten. Im
einfachsten Fall kann man die gewünschte Wohnfläche und die Anzahl der
benötigten Zimmer und ein maximales Finanzvolumen festlegen. Gibt es das
gewünschte nicht für den möglichen Finanzierungsrahmen, so muss an den
Anforderungen eine Änderung vorgenommen werden. Gibt es Alternativen,
so müssen weitere Anforderungen (z.B. Unterkellerung oder Größe des
Grundstücks) in die Entscheidung mit einbezogen werden.
Am Ende dieses Verfeinerungsprozesses wird dann die Entscheidung für den
Kauf eines bestimmten Objekts oder das Verwerfen des Plans stehen.
Bei der Entwicklung eines Kommunikationssystems stehen vergleichbar
strukturierte Überlegungen am Anfang.
Für welchen Einsatzfall wird das System geplant?
Wie kann ein Anwender das System später nutzen?
Für welche Zwecke ist das System in keinem Fall brauchbar?
Welche technischen Rahmenbedingungen sind bekannt?
Welcher finanzielle Rahmen ist für die Entwicklung und die spätere
Produktion maßgeblich?
Gibt es vergleichbare Systeme, die einen Mindeststandard definieren oder
gegenüber denen eine Differenzierung am Markt notwendig ist?
…
Im Rahmen dieses Praktikums werden ausschließlich technische Aspekte der
Lösung spezifiziert und später verifiziert und validiert. Die folgenden beiden
Abschnitte geben eine Übersicht über die notwendigen Dokumente und Inhalte.
4.2 Formlose Beschreibung des Systemverhaltens
Es sollte zunächst in einem einleitenden Kapitel in bebildertem Fließtext dargestellt
werden, wie die Antworten auf die im vorigen Abschnitt postulierten Fragen
aussehen sollen. In der Regel werden sich Anwender und Entwickler hier zunächst
auf einen losen Rahmen einigen, der später dann in eine Arbeitsplanung und eine
detaillierte Formulierung der Anforderungen entwickelt wird.
Durch die Interaktion in der Gruppe werden Ideen aus dem Vorfeld konkretisiert und
Machbarkeiten von einzelnen Lösungsansätzen abgeschätzt. Insbesondere ist hier
18 Das Anforderungsdokument
auch von Interesse, welcher Bedarf an Werkzeugen, Prototypen und
Zwischenberichten notwendig entsteht, um die kontinuierliche Validierung (in
Anlehnung an Abbildung 3) zu ermöglichen.
Der Übergang in die formalisierte Anforderungsdokumentation ist dann fließend. Im
Laufe des (in der Dokumentenhistorie zu markierenden) Evolutionsprozess des
Dokuments werden die informellen Anforderungen dann konkretisiert.
4.3 Formale Struktur eines Anforderungsdokuments
Ein Anforderungsdokument sollte folgende Elemente enthalten:
Einen Titel, der es eindeutig macht
Eine Liste der Beteiligten Personen
Eine Revisionshistorie
Eine Beschreibung der Adressaten des Dokuments
Eine Übersicht, wofür die Anforderungen gelten.
Die Wechselwirkungen mit anderen Arbeitspaketen (bei Abstimmung mit
anderen Teams)
Eine Übersichte der Anwendungsfälle
Die Liste der detaillierten Anforderungen
Weitere Elemente können nach Bedarf hinzugefügt werden.
Die beschriebenen Inhalte dienen der Nachvollziehbarkeit der Evolution dieses
Dokuments und stellen (siehe Liste der Beteiligten und Adressaten) in hohem Maße
auch sicher, das am Ende genau das entwickelt wurde, was der Anwender gewollt
hatte.
Bei der Beschreibung der Anforderungen müssen pro Anforderung die folgenden
Informationen enthalten sein:
a) Handelt es sich in der Wichtigkeit um einen der folgenden Fälle?
a. Muss,
b. Sollte
c. Kann
b) Warum wurde diese Anforderung in die Liste aufgenommen?
c) Was genau umfasst die Anforderung?
d) Sind zum Erfüllen der Anforderung Vorbedingungen einzuhalten?
e) Ist die Erfüllung der Anforderung Vorbedingung für andere Aktivitäten
(Arbeitspakete) im Projekt?
f) In welchem Arbeitspaket und von wem soll die Anforderung erfüllt werden?
Das Anforderungsdokument sollte möglichst früh im Projektzyklus fertig gestellt
werden. Es ist jedoch auch möglich, auch nach dem Abschluss von Projektphasen
im Einvernehmen der Beteiligten begründete Ergänzungen oder Veränderungen
vorzunehmen.
Ein Beispiel für eine einzelne Anforderung ist im Folgenden gezeigt.
Formale Struktur eines Anforderungsdokuments 19
A21 Warnung bei geringem Batteriestand Muss
Beschreibung:
Bei einem Ladezustand von 40% bzw. eine Restlaufzeit von 2 Tagen
soll eine optische Warnung erfolgen und eine Nachricht versendet
werden.
Begründung:
Der Anwender muss die Möglichkeit erhalten, auf die
Systemwarnung zeitnah zu reagieren und vor dem Ausfall einen
Ladezyklus zu starten
Abhängigkeiten: Hardwaregruppe: Ladestanderfassung
Kommunikation: Messaging Schnittstelle
Zusätzliche
Informationen
Müller AP 3
21
5 Arbeitsablauf der automatisierten Entwicklung
5.1 Definition von Anwendungsfällen (Use-Cases)
5.1.1 Nutzung von Anwendungsfällen
Am Anfang jeder Entwicklung steht die Entscheidung, was genau entwickelt werden
soll. Die Antwort auf diese Frage wird aus funktionaler Sicht im Wesentlichen
dadurch bestimmt, wo und zu welchem Zweck die entwickelte Komponente bzw.
das entwickelte System eingesetzt werden soll. Diese Betrachtung ist aus
mindestens zwei Aspekten notwendig:
1) Effiziente Entwicklung schließt ein, dass die Anforderungen erfüllt werden
und nicht mehr.
2) Hoch qualitative Entwicklung bedeutet, dass die Erwartungen an ein System
erfüllt werden.
Für beide Aspekte ist es wichtig, die Beschaffenheit des Anwendungsfalles (Use-
Case) sowie die potentiellen Erwartungen der Anwender sowie deren vorgesehene
Interaktion zu kennen oder zu definieren.
Im Rahmen von Überlegungen zur Produktsicherheit und zu Haftungsfragen ist es
zusätzlich wichtig, die so genannten „bestimmungsgemäße Verwendung“ eines
Systems möglichst genau zu definieren. Der Hersteller haftet nicht, wenn der
Betreiber einen ausgeschlossenen Use-Case ausführt und es dabei zu
Fehlfunktionen kommt.
Das UML Use-Case Diagramm adressiert dieses Problemfeld und bietet Elemente,
die auf einem hohen Abstraktionsniveau Verständnis von einem System und seinen
Einsatzfällen schaffen können, ohne hierzu technische Detailkenntnisse zu
erfordern.
Eine frei verfügbare Beschreibung dieses Diagrammtyps findet sich unter
http://www.jeckle.de/uml-glasklar/UseCaseDiagramm.pdf.
Use–Cases, oder auch Szenarien, sollen verdeutlichen, welche Systeme oder
Systemteile mit dem Endanwender (oder allgemein mit dem Umfeld des Systems)
interagieren und welche Art der Interaktion grundsätzlich vorgesehen ist.
5.1.2 Die Use–Case Notation
Use–Cases werden in der UML grundsätzlich aus folgenden Elementen konstruiert
System
Unter System wird eine Entität verstanden, die
später tatsächlich implementiert wird. Systeme
müssen eindeutig benannt sein. Eine Lösung kann
aus der Kombination von interagierenden Systemen
bestehen.
<Systemname>
22 Arbeitsablauf der automatisierten Entwicklung
Akteure
Akteure, häufg durch Strichmännchen
symbolisiert, sind immer extern vom System
anzusiedeln und beeinflussen das
Systemverhalten durch Interaktion.
Da es sich bei einem Akteur zunächst nur um
ein Symbol handelt, können Sie hier auch
andere, deskriptivere Symbole wählen.
Use Case
Anwendungsfall, also ein Vorgang, der an oder
mit dem System ausgeführt wird. Es wird
angenommen, dass Use Cases als
Systemfunktionen abgebildet werden. Sie sind
daher in den Systemgrenzen zu zeichnen.
Use Cases benötigen einen eindeutigen
Namen (Identifier), z.B. „Grünanforderung“ i
unserer Fallstudie.
Beziehungen
Zwischen den graphischen Komponenten des
Modelles. Dies können
Interaktionen
Generalisierungen
oder Abhängigkeiten
sein.
Wichtig bei Generalisierungen: An der Spitze
des Pfeils ist die generelle Instanz, die am
anderen Ende ist die Spezialisierung
Abhängigkeiten werden in der Regel mit so
genannten Stereotypen dekoriert, um die
Verständlichkeit zu erhöhen. Im gezeigten
Beispiel bedeutet die Notation „<<includes>>,
dass der Use Case der automatischen
Türöffnung den Fall einschließt, dass eine
Annäherungsdetektion wirksam durchgeführt
wurde.
Tür öffnen
Eintreten
Tür öffnen
manuell öffnen
automatisch öffnen
<Use Case>
Definition von Anwendungsfällen (Use-Cases) 23
Im UML Use Case Diagram gibt es noch weitere Möglichkeiten der Strukturierung.
So können z.B. dem Use Case Klassenattribute zur Seite gestellt werden, um die
Implementierung dieses Anwendungsfalls durch einen bestimmten Objekttyp zu
symbolisieren.
Ebenso ist es möglich, deskriptiv eine Abfolge derjenigen Aktivitäten zu
beschreiben, die einen solchen Use Case ausmachen.
Use Cases besitzen allerdings keine generelle Semantik die hier zu einer
Codegenerierung herangezogen werden kann.
Im Rahmen dieses Praktikums werden Use Cases daher ausschließlich zur
Anforderungsdokumentation verwendet.
5.1.3 Alternative Methoden zur Definition (z.B. Mindmaps)
Der Prozess der Ideenfindung bei der Erstellung des Anforderungsdokuments kann
auch mit anderen Methoden unterstützt werden. Eine solche Methode ist das so
genannte Mind Mapping. Ein Beispiel ist in Abbildung 6 dargestellt.
Abbildung 6: Beispiel für eine Mind Map
Das Ziel des Mind Mappings ist es dabei nicht, konkrete Anforderungen abzubilden.
Vielmehr besteht der Nutzen darin, dass ein Team sich auf strukturierte Weise
einem (bis dahin unbekannten Thema) nähert und so leicht die Ideen mehrerer
Personen zusammenführen kann.
In der Regel erfolgt das Mindmapping in 4 Schritten:
1) Zentrales Thema, z.B. den Titel der Fallstudie, in die Mitte schreiben.
Annäherung erkennen
automatisch öffnen
<<inclu
des>>
24 Arbeitsablauf der automatisierten Entwicklung
2) Sammeln von Schlüsselwörtern die einem zum Thema einfallen.
3) Strukturieren der Schlüsselwörter nach Kategorien. Diese können auch
hierarchisch gegliedert sein.
4) Diskussion und Verfeinerung der Mindmap.
An diesem Punkt angekommen, bietet eine Mindmap z.B. eine Übersicht, welche
Use Cases für das von Ihnen betrachtete Problem in Frage kommen oder welche
Systemelemente für ein Funktionieren notwendig sind.
5.2 Definition der geforderten Systemkomponenten
5.2.1 Rollen von physischen Komponenten
Die Betrachtung der UML Use Cases führt schnell zum Verständnis eines
Rollenmodells, das Antworten auf die Fragen nach dem „Wer macht was“ gibt. Im
Schritt der Rollenzuweisung wird festgelegt, welche (Teil-) Funktionen an welcher
Stelle implementiert bzw. genutzt werden sollen.
Bei der Betrachtung der Abbildung 2 fällt z.B. auf, dass nur eine der
Hardwarekomponenten einen direkten Kontakt zu einem PC hat. Damit kann dieses
Systemelement Aufgaben übernehmen, die den anderen unmöglich sind und
bekommt so eine besondere Rolle.
Unter Umständen kann es sinnvoll sein, die eingangs gestellte Frage zur Frage
„Wer macht wann was?“ zu erweitern, um den Aspekt der temporalen
Rollenzuweisung zu adressieren. Damit ist gemeint, dass eine Systemkomponente
im Zeitablauf unterschiedliche Rollen annehmen kann.
Als Auslöser für eine solche Überlegung kann zum Beispiel die Erkenntnis dienen,
dass eine Funkkommunikation unerwartet gestört werden kann und in diesem Fall
eine plötzlich isolierte Komponente eine neue Rolle (z.B. autonome Notfunktion)
übernehmen können muss.
Rollen können im Use Case Diagramm z.B. über Kommentare definiert werden.
Abhängig von den Rollen werden bestimmte Ressourcen benötigt, z.B. eine
hinreichende Anzahl von Ein– und Ausgabekanälen zur Kommunikation einer
Komponente mit der Umwelt, eine Funkschnittstelle zum Austausch von Daten o.ä.
Am Ende dieses Schrittes steht dann eine Liste aller Ressourcen, mit denen die
geplanten Anforderungen realisiert werden sollten. Im praktischen Einsatz kann nun
eine Kostenkalkulation beginnen und mit dem Endanwender validiert werden, ob
das geplante System akzeptabel ist oder Änderungen gepflegt werden müssen.
5.2.2 Aufgaben von Softwarekomponenten
Für die Softwarekomponenten gilt im Wesentlichen das eben Gesagte. Allerdings
kann eine Softwarekomponente nicht ohne eine passende Hardwareplattform
ausgeführt werden. Softwarekomponenten repräsentieren grundsätzlich Zustände
der physischen Plattform (in Form von Daten) und stellen funktionale Abläufe bereit.
Mit Hilfe von Use–Cases und Mind Maps sollte isoliert werden, welche
Funktionsblöcke die spätere Softwarelösung benötigt. Auch eine detailliertere
Beschreibung der Interaktion der Blöcke mit der Außenwelt ist nun möglich. Im
Definition der Wirkungszusammenhänge 25
Allgemeinen sollten nun auch Rahmenbedingungen wie Parameter und deren
Inhalte bekannt sein.
5.3 Definition der Wirkungszusammenhänge
5.3.1 Inter-Komponenten Kommunikation
Parallel zur Spezifikation der Ausgestaltung der Systemkomponenten wird auch
deren Kommunikation untereinander definiert. Für jede Systemkomponente sind
demnach mögliche Eingangssignale, gesteuerte Ausgangssignale und bei Bedarf
die ausgetauschten Nachrichten zu definieren. Zur Illustration des geplanten
Nachrichtenaustauschs wird hier in der Regel auf so genannte „Message–
Sequence–Charts (MSCs)“ zurückgegriffen. In der Vorlesung Kommunikationsnetze
wurden solche Charts bei der Besprechung von Sicherungsprotokollen besprochen.
Abbildung 7: Beispiel für ein Message-Sequence-Chart
In UML gestaltet sich die Darstellung dieses Diagramm formaler, in dem jedem
kommunizierenden Objekt eine senkrecht verlaufende Zeitlinie zugeordnet. Am
oberen Ende der Zeitlinie ist der Typ des agierenden Objekts zusammen mit einer
Objektreferenz (dem Namen eben dieser Objektinstanz) vermerkt. Auf der Zeitlinie
sind in der Reihenfolge des Auftretens Operationen und Aktionen vermerkt.
Operationen sind als Textblöcke vermerkt, Aktionen als horizontale Linien, die bei
der Übertragung von einem zum anderen Objekt gezeichnet werden. Im Ablauf von
oben nach unten ergibt sich die Reihenfolge der Nachrichten.
Jedes Message–Sequence–Chart beschreibt GENAU EINE mögliche
Abfolge eines Nachrichtenaustauschs zwischen den beteiligten
Systemkomponenten!
Es ist sofort klar, dass ab einer bestimmten Anzahl von potentiellen
Kommunikationspartnern und einer hinreichend mächtigen Sprache, d.h. der Menge
unterscheidbarer Nachrichten, eine vollständige Abbildung des Systemverhaltens in
dieser Weise nicht mehr praktikabel ist. Abbildung 8 stellt ein solches, formalisiertes
Message–Sequence–Chart dar, wie es später bei der Definition von Systemtests
Verwendung findet.
26 Arbeitsablauf der automatisierten Entwicklung
Abbildung 8: Illustration eine Message–Sequence–Charts
Die Mächtigkeit der MSCs liegt in der anschaulichen und zusammenhängenden
Darstellung der auftretenden Ein– und Ausgangssignale einer Systemkomponente.
Darüber hinaus kann in vielen Fällen mit formalen Mitteln (nicht Gegenstand dieses
Praktikums) nachgewiesen werden, dass ein bestimmter Ablauf durch eine
gegebene Implementierung realisiert werden kann oder eben nicht. Damit dient ein
MSC auch der Verifikation innerhalb des Entwicklungsprozesses und, bei der
Einsatz als Testwerkzeug, der Validierung des Gesamtsystems.
5.3.2 Beschreibung von Testfällen
Indem nun bekannt ist, welche Systemkomponenten für welche Rollen vorgesehen
sind und welche Interaktion diese Komponenten in den Rollen miteinander und mit
der Umgebung haben werden, ist auch die erste Definition von Tests möglich. So ist
an dieser Stelle formulierbar, was Anforderungen im Detail bedeuten. Ein Beispiel:
Anforderung: Nach dem Drücken des Knopfes erwarte ich sofort das
Umschalten der Lampe.
Definition der Wirkungszusammenhänge 27
Systemwissen: der Anwender (Mensch) hat eine optische Reaktionszeit von ca.
100ms. Reaktionszeiten unter dieser Schwelle werden als
„sofort“ empfunden.
Test: Systemreaktionszeit
1) Erfasse nach dem Drücken des Knopfes die aktuelle
Systemzeit.
2) Erfasse beim Umschalten der Lampe die Systemzeit.
3) Bilde die Differenz der Werte und gebe sie als Reaktionszeit
aus.
Verdict: Wenn die gemessene Reaktionszeit kleiner als 100ms ist, so ist
die Anforderung erfüllt, das System hat den Test bestanden.
Bei der Beschreibung der Testfälle ist zu beachten, dass Sie für die
unterschiedlichen Phasen der Entwicklung zugeschnitten sein müssen. Im Regelfall
wird hierbei dem so genannten „V“–Modell Anwendung finden, wie in Abbildung 9
dargestellt. Auf der linken Seite ist die Verfeinerung der Anforderungen bis zur
finalen Implementierung dargestellt. Hierbei führt die Pflege der Referenzdokumente
und Modelle im Zusammenspiel mit Tests zu einer Verifikation der Lösung. Auf der
rechten Seite erfolgt in umgekehrter Reihenfolge im Legoprinzip das
Zusammensetzen der Gesamtlösung und die schrittweise Validierung des fertigen
Systems.
Die Definition von Testfällen geschieht im Idealfall bereits parallel zum Entwurf der
Lösung. Nur in diesem Fall kann sichergestellt werden, dass alle für einen späteren
Test notwendigen Signale und Informationen auch problemlos während eines Tests
abrufbar sind.
Aus dem in Abbildung 9 dargestellten „V“–Modell ist auch direkt ersichtlich, dass die
Automation von Schritten beim Übergang von der Anforderung zum Code die
Verifikation und Validierung vereinfacht. In diesem Fall werden unter Umständen
Abbildung 9: Illustration der Testabläufe am V–Modell
Ver
ifik
atio
n
Coding
Moduldesign Modultest
Integrations-test
Feinentwurf
Grobentwurf Systemtest
Anforderungs-definition
AbnahmetestReviews,Prototypen
Reviews,Konsistenzprüfungen,Machbarkeitsstudien
Modellierung,Simulationen
Code Review,Testplanung
Komponentenmodelle
Grundlage für
Grundlage für
Grundlage für
Grundlage für
Grundlage für
Grundlage für Val
idie
run
g
28 Arbeitsablauf der automatisierten Entwicklung
Ebenen, z.B. die Codierungsebene oder Teile des Moduldesigns im V–Modell nicht
mehr auftreten und somit auch bei weiteren Entwicklungen nicht mehr modifiziert.
Dies gilt natürlich nur unter der Voraussetzung, dass die Transformation von einem
Modell zu lauffähigem Code selbst verifiziert und validiert worden ist.
5.4 Eingabe der Zustandsautomaten (State-Charts)
5.4.1 UML State–Charts vs. SDL
a) UML b) SDL
Abbildung 10: Zwei Statecharts
UML State–Charts sind ebenso wie die SDL dafür entworfen, so genannte endliche
Automaten (Finite State Machines, FSMs) abzubilden. Theoretisch setzt sich ein
solcher Automat als ein Graph aus Knoten (den Zuständen) und gerichteten Kanten
(den bedingten Zustandsübergängen) zusammen.
Ein sehr einfaches UML State–Chart (a) mit 2 Zuständen ist parallel zu einem
Modell mit identischer Semantik in SDL (b) in Abbildung 10 abgebildet. In beiden
Fällen wird das Verhalten einer Lampe auf das Drücken eines Tasters beschrieben.
Beide Beschreibungen implizieren, dass nach dem Einschalten des Systems
zunächst die Lampe ausgeschaltet wird. In UML wird diese Einschaltbedingung
durch den Initalisierungszustand repräsentiert, von dem ein direkter Übergang zu
einem anderen Zustand vorhanden sein muss.
In SDL wird hingegen das „Reset“ Signal explizit angegeben, das aus jedem
beliebigen Zustand (*) in einen definierten Anfangszustand führt.
Folgende Regeln gelten für die Notation im SDL Diagramm:
Die FSM ruht immer in einem Zustand
Für jeden Zustand existiert eine wohldefinierte Menge von Eingangsgrößen,
auf die das System reagiert. Eine abgehende Kante von einem Zustand
muss immer auf einem solchen Eingangsereignis enden.
off
on
onOff1
Lampe einschalten
on
off
onOff1
Lampe ausschalten
*
Reset
off
Lampe ausschalten
Eingabe der Zustandsautomaten (State-Charts) 29
Die Eingangsereignisse, die von einem Zustand aus erreicht werden, müssen
disjunkt sein.
Jedes Eingangsereignis führt über einen eindeutigen Pfad zu einen nächsten
Zustand
Auf der Kante, die vom Eingangsereignis zum nächsten Zustand führt,
werden alle Operationen (Prozeduraufrufe) und Aktionen
(Ausgangsereignisse ) in der Reihenfolge ihrer Ausführung notiert.
Bei großen SDL State–Charts wird häufig für jeden Zustand ein Zeichenblatt
verwendet und dort dann alle abgehenden Ereignisse parallel aufgetragen.
Die erste Version von SDL wurde 1976 veröffentlicht. Seit Mitte der 1980’er Jahre
existieren erste Code-Generatoren, die aus der grafischen Beschreibung
ausführbaren Code erzeugen konnten. Seit 2000 existiert eine mit UML
harmonisierte Version. SDL bietet den Vorzug, bei der Übertragung von Nachrichten
(dem Senden von Events) explizit die Verzögerung des verwendeten Kanals
angeben zu können. So wurde es sehr früh möglich, komplexe Systeme zu
modellieren und zu simulieren.
Region
Eine Region ist ein Zeichenbereich, der eine
FSM aufnimmt. Regionen werden in
unabhängige Gültigkeitsbereiche im Code
transformiert.
Initial State
Dieser gefüllte Punkt muss in einer Region genau
einmal vorkommen und markiert die Stelle, an
der die Ausführung der FSM beginnt
State
Ein Zustand, in dem die FSM beliebig lange
ruhen kann. Ein Zustand wird nur auf Grund von
Ereignissen verlassen
Transition
Gerichtete Kante zwischen zwei Zuständen
Choice
Dieser Auswahlzustand kann das Ziel einer
Transition sein. Die FSM kann aber nicht in Ihm
verharren sondern muss über weitere Transitions
mit oder ohne Bedingung sofort wieder verlassen
werden.
Event Notation
Diese Beschreibung kann States oder Transitions
hinzugefügt werden.
Event
Event/action (‚;‘ action)*
Event[guard]/action (‚;‘ action)*
<name>
30 Arbeitsablauf der automatisierten Entwicklung
UML State–Charts haben diese Funktionen und Möglichkeiten inzwischen
weitestgehend assimiliert. Die vereinfachte Notation erlaubt eine stark verdichtete
Darstellung. Die in der obigen Tabelle dargestellten Konstrukte finden in diesem
Praktikum Anwendung.
5.4.2 Eingabe eines State–Charts
YAKINDU und der zugehörige State–Chart Simulator sind in Java implementiert.
Die Eingabe der textuellen Anteile orientiert sich daher weitgehend an dieser
Syntax.
Nach dem Anlegen eines neuen YAKINDU State–Charts muss zunächst eine neue
Datei im Workspace erstellt werden. Wählen Sie dazu File->New->YAKINDU
Statechart Model aus.
Im anschließenden Dialog geben Sie der Datei einen eindeutigen Namen und
Drücken „Finish“. Achten Sie darauf, dass Ihre Eingabe auf „.sct“ endet, um die
korrekte Behandlung des Modells im Workspace sicher zu stellen.
Im geöffneten Fenster sehen Sie einen minimalen State–Chart
Das rote Kreuz an der oberen rechten Ecke des einzigen Zustandes zeigt an, dass
hier noch kein Name vergeben wurde. Es verschwindet nach einer gültigen
Eingabe. (Es muss sich hierbei um einen in Java gültigen Bezeichner handeln!)
Nach einem Klick auf das Rechteck unter „MyChart“ (das nach außen sichtbare
Interface dieses State–Charts) sehen Sie im unteren Bildschirmbereich ein
„Properties“ Feld, in dem Sie nun die Schnittstellenbeschreibung eingeben können.
Ebenso wie beim Interface ist es auch bei allen anderen grafischen Elementen
möglich, „Properties“, also Attribute, anzugeben. Zu diesen Properties gehören auch
Eingabe der Zustandsautomaten (State-Charts) 31
die in der obigen Tabelle angeführten „Events“. Die formale Notation eines Events
ist wie folgt:
<leer> Unbedingter, sofortiger Übergang
EventName Transition wird beim Eintreffen des
Ereignisses „EventName“ ausgelöst
EventName[guard] Das Ereignis „Event“ wird nur erkannt,
wenn die Bedingung „guard“ wahr ist
[guard] Sofortiger Übergang wenn die
Bedingung „guard“ wahr ist.
EventName/action (‚;‘ action)* Die Transition wird ausgelöst, wenn
„EventName“ eingetroffen ist. Danach
wird die Liste der durch Semikola
getrennten Aktionen ausgeführt.
after <time> Zum Zeitpunkt „time“ nach dem Eintritt
in den Startzustand der Transition wird
diese ausgelöst. Der Wert „100ms“ löst
also einen Zustandsübergang nach 100
ms aus.
Die in „action“ gelisteten Anweisungen werden ausgeführt, wenn die referenzierte
Transition ausgelöst wurde. Es ist dabei zu beachten, dass an dieser Stelle nur eine
eingeschränkte Java Syntax (siehe auch Abschnitt 5.4.3) erlaubt ist.
Der State–Chart Editor ist kontextsensitiv und stellt bei Fehleingaben an den
Fehlerpositionen ein weißes Kreuz auf rotem Hintergrund dar, das mit dem
Mauszeiger zu einer Erläuterung erweitert werden kann.
5.4.3 Restriktionen bei der Eingabe
Bei der Eingabe der Modelle ist zu berücksichtigen, dass die Systemmodelle zum
Zielsystem kompatibel sein müssen. Im Zielsystem können z.B. manche
Variablennamen oder Funktionsnamen vordefiniert sein. Wird ein solcher Name
innerhalb des Modells, in dem er keine spezifische Bedeutung hat, verwendet, so
ergeben sich bei der Zusammenführung mit der Zielplattform Probleme bei der
Compilation oder dem Linken des Codes.
Des Weiteren ist zu berücksichtigen, dass die automatisierte, modellgetriebene
Systementwicklung auch von der simultanen Simulationsmöglichkeit (siehe auch
Abschnitt 5.5) profitiert. Da es sich beim Simulator auch um ein eigenständiges
System handelt, sind auch dessen Rahmenbedingungen, insbesondere die
Grammatik der möglichen Notationen, zu berücksichtigen. Die Referenz der
möglichen Konstrukte finden Sie unter „Help->Content“. Navigieren Sie zur
YAKINDU SCT 2 Reference.
32 Arbeitsablauf der automatisierten Entwicklung
Ein wesentlicher Punkt bei der Eingabe eines State–Charts ist die Festlegung von
Prioritäten für den Fall, dass ein Zustand auf Grund unterschiedlicher Ereignisse in
verschiedener Weise verlassen werden kann. Diese Priorisierung wird bei der
Modelleingabe unter den Eigenschaften (Properties) der Zustände vorgenommen.
Existieren mehrere abgehende Transitionen, so werden die Schaltknöpfe „up/down“
aktiv und die Transitionen können sortiert werden. Dabei werden bei der
Bearbeitung des Zustandes (siehe auch Abschnitt 5.5.2) die Transitionen von oben
nach unten abgearbeitet.
5.5 Simulation des Systemverhaltens
5.5.1 Planung der Simulation
Die YAKINDU State–Chart Tools ermöglichen neben der Eingabe der UML State–
Charts auch direkt deren Simulation. Für einen effektiven Einsatz dieser Option ist
es notwendig, vor dem eigentlichen Simulationslauf den Inhalt zu planen. Dazu
gehören:
1) Auflistung aller zu generierender Eingangssignale und Ereignisse
2) Definition von Reihenfolgen und Zeitpunkten für die Anreizgenerierung
3) Auflistung aller zu beobachtenden Ausgangsvariablen.
Dies Variablen und Ereignisse stellen dies externen Schnittstellen Ihres Systems
dar, die Sie vorher im Interface Block des Modells eingegeben haben.
Simulation des Systemverhaltens 33
Eingangssignale sind dabei solche Variablen, die durch den modellierten Prozess
nicht verändert werden. So können Sie z.B. die aktive Messung einer Temperatur
dadurch modellieren, dass Sie eine Variable „Temperatur“ und ein Ereignis (event)
„Messen“ definieren. Der Ausdruck „Messen[Temperatur>38]/Fieber = true“ ist dann
die entsprechende Modellierung mit einer Kombination aus Ereignis und
Eingangssignal.
5.5.2 Durchführung der Simulation
Selektieren Sie zur Simulation mit der rechten Maustaste das zu simulierende
State–Chart im Projectexplorer und wählen Sie dann „Run As“->YAKINDU
Statechart“.
Die Debuggeransicht öffnet sich und auf der rechten Seite öffnet sich ein Abschnitt
mit dem „Simulation View“.
Die Variablen können Sie nun mittels eines In–Place Editors modifizieren und dann
durch klicken auf die als Link unterlegten Ereignisse diese Auslösen. Der Simulator
startet dann den für den aktuellen Zustand unter Berücksichtigung des
Eingangsevents modellierten Vorgang. Durch Druck auf die
„Pause“ Taste des Debuggers kann die Verarbeitung jederzeit
unterbrochen und danach neu gestartet werden.
Grundsätzlich wird bei der Ausführung der State–Charts zwischen zwei
unterschiedlichen Verfahren unterschieden:
a) Cycle-based execution
b) Event-driven execution
Im ersten Fall wird regelmäßig durch eine externe Ausführungseinheit die Methode
„runCycle“ des State–Charts aufgerufen. In dieser werden dann, abhängig vom
aktuellen Zustand der FSM, die vorhandenen Eingangsevents abgesucht,
Eingangsbedingungen überprüft und die relevante Transition eingeleitet. Dieses
Verfahren hat den Vorteil, dass immer genau ein Thread den Code der FSM
ausführt und somit Probleme der Nebenläufigkeit von Prozessen komplett
vermieden werden. Eingangsereignisse werden in diesem Fall allerdings erst nach
der Beendigung des aktuellen Zyklus erkannt und es kommt so zu undefinierten
Verzögerungszeiten (Latenz) zwischen dem Auftreten des Ereignisses und dessen
34 Arbeitsablauf der automatisierten Entwicklung
Bearbeitung. Liegen mehrere Ereignisse an, so muss über Priorisierung der
Transitionen eine Abfragereihenfolge definiert werden.
Im zweiten Fall erfolgt dieser regelmäßige Aufruf nicht sondern nur genau dann,
wenn ein Ereignis auftritt. Dieses Verfahren vermeidet weitestgehend die Latenz bei
der Eventbearbeitung. Dieses Ausführungsmodell ist jedoch dahingehend stark von
der Laufzeitumgebung abhängig, als dass zum Zeitpunkt der Modellierung eine
Nebenläufigkeit der späteren Ausführung nicht ausgeschlossen werden kann.
Um Probleme mit Nebenläufigkeiten zu vermeiden wird in diesem Praktikum
ausschließlich die „Cycle-based execution“ verwendet.
5.5.3 Interpretation der Ergebnisse
Während der Simulation zeigt der Simulator die aktuelle Systemzeit zusammen mit
einer grafischen Markierung des jeweils aktiven Zustands sowie der verwendeten
Übergänge an. Eine Interpretation dieser Anzeigen geschieht jedoch ausschließlich
durch den Anwender.
Daher sollte vor der Durchführung einer Simulation zusätzlich zu den bereits
genannten Aspekten auch eine Liste von erwarteten Systemzuständen und
Ausgangsgrößen angefertigt werden.
Die Simulationsergebnisse sind erst dann nachvollziehbar in Kategorien wie „OK“
oder „fehlerhaft“ zu klassifizieren.
5.6 Erzeugung von ausführbarem Quelltext
5.6.1 Codegenerierung aus abstraktem Modell
Nach der Verifikation der Modellierung des geplanten Systems schließt sich die
automatische Generierung von Quelltexten für die Zielplattformen an. Im
Beispielprojekt wird automatisch eine Datei „GenModelJava.sgen“ installiert. Nach
dem Öffnen dieser Datei im Editor zeigt sich folgender Inhalt:
In der ersten Zeile ist die Zielsprache des Generators erkennbar (hier Java). Im
nächsten Block wird identifiziert, welches State–Chart aus dem Arbeitsbereich
Erzeugung von ausführbarem Quelltext 35
transformiert werden soll. (hier TrafficLightWaiting). Für die Codegenerierung im
Rahmen dieses Praktikums sind die beiden nächsten Blöcke ebenfalls wichtig.
Der Block „Outlet“ definiert das Eclipse Projekt und den Dateiordner, in dem der
automatisch generierte Code abgelegt wird.
Der Block „Naming“ beschreibt, welche Konventionen bezüglich der externen
Schnittstellen des autogenerierten Codes Verwendung finden. Die Einstellung
„cyclebased“ ist hier die Standardvorgabe und wird während des Praktikums nicht
verändert.
Eine neue Steuerdatei für einen Code–Generator kann mittels „New->YAKUNDU
statechart generator model“ angelegt werden.
Selektieren Sie im sich öffnenden Dialog das Projekt, in dem sich das zu
übersetzende State–Chart befindet und geben Sie dem Generator einen geeigneten
Namen. Achten Sie dabei darauf, dass die Dateiendung „sgen“ heißen muss.
Durch Drücken des Knopfes „Next“ gelangen Sie zur Auswahl der Zielsprache und
zur Auswahl des zu konvertierenden State–Charts.
36 Arbeitsablauf der automatisierten Entwicklung
In hier gezeigten Falle wurde die Sprache „C“ als Ziel ausgewählt. Beachten sie,
dass in einem Projekt mehrere Generatoren parallel existieren dürfen. Sie können
also mehrere State–Charts und mehrere Zielsprachen simultan verwenden.
Das Drücken von „Finish“ veranlasst nun die Erzeugung der Steuerdatei.
Einstellungen über den Zielordner, in den die generierten Daten ausgegeben
werden, müssen nachträglich manuell in der oben beschriebenen Steuerdatei
erfolgen.
5.6.2 Verstehen des erzeugten ‚C‘-Codes
Nach der Codegenerierung entsteht im Zielordner eine Datei
„<statechartname>Required.h“. In dieser Datei ist die Signatur zweier notwendiger
Funktionen hinterlegt, mit denen ein Timer gestartet und gestoppt werden kann. Da
die Behandlung von Zeitgebern systemabhängig ist, muss für eine funktionierende
Einbettung des generierten Codes in das Zielsystem die Implementierung dieser
Funktionen manuell erfolgen.
Hinweis:
Diese manuelle Arbeit fällt nur einmal pro Zielplattform an, da für alle
möglichen State–Charts aus der hier verwendeten Werkzeugkette ein und
dasselbe Interface mit der Plattform verwendet wird.
5.6.3 Funktion der Steuerungskonstrukte
Neben der Implementierung der Timer Schnittstellen muss zusätzlich noch die
Ausführung des Codes auf der Zielplattform implementiert werden. Für die
Programmierung unter ‚C‘ gilt die Konvention, dass die Ausführung eines
Programms immer in der Routine „main“ beginnt. Hier müssen nun die folgenden
Schritte implementiert werden.
a) Initialisierung aller für die geplante Funktion benötigten Systemfunktionen. (in
Soft– und Hardware)
b) Eine Endlosschleife, in der zunächst die vorhandenen Ereignisse an die
State–Chart Implementierung gemeldet werden. Danach folgt die Ausführung
eines Zyklus und schließlich die Auswertung der Ergebnisse in
entsprechende Hardware-I/Os oder Nachrichten.
Auch diese Funktionen sind grundsätzlich nicht für jede Aufgabe neu zu erstellen
sondern für bestimmte Klassen von Anwendungen ganz oder teilweise
wiederverwendbar. Zuordnungskriterium zu einer solchen Klasse kann z.B. die
Menge und Art der verwendeten I/O-Ressourcen des Zielsystems sein.
Einbettung in die Systemumgebung 37
5.7 Einbettung in die Systemumgebung
5.7.1 Erstellung eines Software-Rahmens für die Ausführung
Die Einbettung in die Zielumgebung erfolgt grundsätzlich durch die manuelle
Erstellung eines Programms in der Programmiersprache des Zielsystems. Hierzu
wird im Rahmen des Praktikums zunächst unter Eclipse ein entsprechendes ‚C‘–
Projekt angelegt. Selektieren Sie „File->New->Other“ (wie schon in Abschnitt 3.1.1
erläutert) und navigieren Sie zum C/C++ Ordner und wählen Sie ein „C“ Projekt aus,
benennen Sie dieses und stellen Sie sicher, das als Ziel eine leere „AVR Cross
Target Application“ erstellt wird.
Fügen sie diesem Projekt zwei weitere Quelltextordner hinzu. In einem soll das
Software Framework manuell codiert werden, im anderen soll der Codegenerator
seine Ergebnisse ablegen.
Es empfiehlt sich dabei, im Framework zur besseren Übersicht und einfachen
Weitergabe des Codes mehrere Dateien ablegen, die später die unterschiedlichen
Funktionen der Abbildung der Systemschnittstellen vornehmen.
Hinweis:
Während der Versuchsdurchführung wird das Skelett eines Softwarerahmens
mit einer Musterstruktur vorgegeben.
Dieser Arbeitsschritt endet mit der erfolgreichen Compilation (ohne Fehler) des
Frameworks zusammen mit den autogenerierten Code.
5.7.2 Abbildung (Codierung) von Variablen auf physikalische I/O Komponenten
Nach der Implementierung des funktionalen Skeletts ist es zusätzlich noch
notwendig, den Programmvariablen des State–Charts physische Bedeutung
beizumessen.
Zu diesem Zweck wird zunächst eine Tabelle angefertigt, in der Variablen des
State–Charts mit physikalischen Ressourcen assoziiert werden. Es ist zu
empfehlen, den Zugriff auf diese Ressourcen zunächst in eigene Zugriffsfunktionen
zu kapseln, z.B. „void hw_set_Traffic_Light_Red( bool value )“. Das Präfix „hw_“
garantiert, dass es zu keinen Namensüberschneidungen mit den automatisch
generierten Codeteilen kommt.
Dieses Vorgehen unterstützt auch bei weiteren Entwicklungen die Vermeidung von
Fehlern, in dem versehentlich falsche Schnittstellen aktiviert werden.
5.7.3 Vom Code-Review zum Integrationstest
Nach der Vervollständigung des manuell erstellten Softwarerahmens muss die
einwandfreie Funktion im Sinne der Definition verifiziert werden. Hierzu sollten
folgende Schritte eingehalten werden (eine fehlerfeie Erzeugung des Binärcodes
vorausgesetzt):
1) Code-Review
Im Team werden die entwickelten Quelltextpassagen nach dem 4 Augen
Prinzip noch einmal überprüft. Unklare Codepassagen sollten modifiziert und
38 Arbeitsablauf der automatisierten Entwicklung
kommentiert werden, so dass die am Review Beteiligten sich über Funktion
und Bedeutung einig sind.
2) Implementierung von Modultests
Ein simpler Test kann z.B. den Aufruf aller Schnittstellenfunktionen mit allen
Parametervariationen enthalten. Typisch kann man hier auch
Initialisierungsfunktionen nutzen. Der Sinn der Modultests ist es, möglichst
weitgehend sicher zu stellen, dass die erwünschten Funktionen auch
tatsächlich im Quellcode abgebildet wurden und ein späterer, automatisierter
Aufruf genau die gewünschten Effekte auslösen.
Es ist zu beachten, dass eine vollständige Prüfung im Regelfall nicht möglich
sein wird und es der Sorgfalt und Kreativität des Entwicklers obliegt, bereits
in der Entwurfsphase ein effizient durch Dritte testbares Design zu
definieren.
Modultests bedeuten in der Regel die Erstellung und die Ausführung von
Code, der in der finalen Software nicht mehr vorhanden sein wird.
3) Ausführung der Modultest
Hierzu bieten sich zunächst Debugger an, mit denen die Implementierten
Funktionen durchlaufen, Preconditions eingestellt und Postconditions, wie
z.B. Registerwerte, überprüft werden können.
4) Durchführung von Integrationstest
Nach der erfolgreichen Durchführung der Modultests kann zum ersten Mal
die aus der gesamten Wirkungskette entstehende Software zusammen auf
der Zielplattform ausgeführt werden. Da die „Integration“ sich ausschließlich
auf die Schnittstellen zwischen dem State–Chart und der Plattform bezieht,
ist es unter Umständen sinnvoll, für einen ersten Test die funktionalen
Aspekte durch eine vereinfachten State–Chart nur für Testzwecke zu
ersetzen.
5.7.4 Definition von Testschnittstellen
Nach dem Integrationstest soll das Komplettsystem auf korrekte Funktion überprüft
werden. Dieser Systemtest ist in der Regel deutlich komplexer als die vorgelagerten
Testfälle. Zur Handhabung dieser Komplexität werden häufig Testautomaten
eingesetzt, die in vordefinierter Weise die Funktion der Systemumgebung
übernehmen.
Zur Nutzung dieser Funktionen ist es allerdings notwendig, eine Schnittstelle
zwischen dem zu testenden System und einem entsprechenden Testautomaten
herzustellen. Alle relevanten Informationen über Zustandswechsel müssen daher
nach außen geführt werden, alle relevanten Eingangsereignisse müssen für einen
solchen Simulator erreichbar sein. Während die erste Bedingung in der Regel als
eine reine Softwarelösung implementierbar ist, kann es für automatische Erzeugung
von Stimuli notwendig sein, spezielle Testsysteme mit angepassten
Hardwareausgängen zu realisieren.
Im Rahmen dieses Praktikums ist die Realisierung von Testschnittstellen allein auf
Softwarelösungen fokussiert. Zur Implementierung werden die in Abschnitt 5.7.2
Implementierung von Tests in TTCN-3 39
eingeführten Zugriffsfunktionen genutzt. Diese sind so zu erweitern, dass parallel
zur Ausgabe eines Wertes auf einen physischen Port auch eine Nachricht zum
Testsystem versandt wird.
Wie schon in früheren Überlegungen ist so die Wechselwirkung zwischen zu
testender Funktion und Testaktivität minimal, denn für das untersuchte System sind
die zusätzlichen Testausgaben bzw, Eingänge simulierter Stimuli hinter der PAL–
Schnittstelle verborgen.
5.8 Implementierung von Tests in TTCN-3
5.8.1 Erfassung von Testfällen
Die Spache TTCN-3 (Test and Testing Control notation, Version 3) bietet einfache
Sprachelemente an, um Tests zu beschreiben. Die Wesentlichen, in diesem
Praktikum verwendeten Elemente zur Ablaufsteuerung sind:
Name Beschreibung
module Namens- und Gültigkeitsbereich eines Tests, umfasst alle weiteren
Statements
function Funktionaler Ablauf eines Testsaspekts. Über definierte
Schnittstellen (Ports) werden Testsignale versendet. Das Warten
auf Reaktionen des SUT wird durch Timer realisiert. Über die
Beschreibung alternativer Reaktion (alt Block) wird die Bewertung
der Testreaktion vorgenommen
testcase Ein (benannter) testcase beschreibt das Vorgehen eines
bestimmten Testfalls. Im Allgemeinen beschreibt ein Testfall
zunächst die Vorbedingungen durch das Setzen von
Konfigurationsvariablen, erzeugt Testautomaten und verbindet dies
mit dem SUT. Abschließend werden dann definierte „functions“ das
geplante Verhalten der Systemumgebung starten.
control Innerhalb eines Moduls entscheidet die Kontrollstruktur, welche
Testfälle in welcher Reihenfolge ausgeführt werden sollen.
Die Notation erfolgt in einer Java–ähnlichen Syntax. Der kompletten Sprachumfang
findet sich in den relevanten Normungsgremien unter http://www.ttcn-
3.org/StandardSuite.htm (für 2012 in der Version 4.4.1).
Die inhaltliche Ausgestaltung der Testfälle orientiert sich an den Vorgaben des
Anforderungsdokuments und kann zunächst formlos erfolgen. Antworten auf die
Fragen „Wer macht wann was?“ und „Welche (System)-Reaktionen erwarten wir
unter gegebenen Randbedingungen?“ stellen zusammen das Grundgerüst für eine
Ausgestaltung eines Testskeletts dar.
Die formale Umsetzung dieser Abfolge von Fragen wird im Praktikum trainiert in
TTCN–3 Sprachkonstrukte wird im Praktikum trainiert.
Hinweis:
Verwechseln Sie einen erfolgreichen Test nicht mit einer fehlerfreien Funktion
des Gesamtsystems. Fällt z.B. die Funkverbindung aus, so ist das in der
40 Arbeitsablauf der automatisierten Entwicklung
Fallstudie betrachtete System sicher in einem „Fehlerzustand“. Die Forderung
„Wenn die Funkverbindung ausfällt, dann müssen die betroffenen Komponenten
in einen sicheren Fehlerzustand wechseln!“ kann gleichwohl erfüllt sein. Ein Test
in der Abfolge:
1) Störe den Funkkanal
2) Warte 2s
3) Alternativen:
a. Wenn der Fehlerzustand eingenommen wurde, markiere das SUT
als OK (pass)
b. Erfolgte keine Reaktion, markiere das SUT als „fehlerhaft“
c. Erfolgte eine Unerwartete Reaktion, markiere das SUT als
„inkonsistent“.
hat offensichtlich einen positiven Ausgang genau dann, wenn die erwartete
Reaktion eingetroffen ist.
Beim Entwurf von Testfällen ist es neben der Spezifikation des Tests unumgänglich,
den Grund für die Durchführung eines Tests nicht aus den Augen zu verlieren.
Analog zur der Verfeinerung der Systemanforderungen werden auch die
Anforderungen an die Aussagekraft von Tests immer detaillierter dargestellt werden
müssen. Alle Tests sollten sich logisch aus Forderungen im Anforderungsdokument
herleiten lassen.
5.8.2 Bewertung der Ergebnisse (verdicts)
„Verdicts“ beschreiben die Bewertung eines Testergebnisses. Sie sind notwendige
Bestandteile der Bewertung von Reaktionen des SUT auf die Ausführung einer
Funktion. Aus der formlosen Beschreibung der Testfälle wird bei der formalen
Umsetzung abgeleitet, in welchen Einzelfällen welche Bewertung angenommen
wird. Werden mehrere Funktionen nacheinander getestet, so kann der Gesamttest
nur dann die Aussage „pass“, erhalten, wenn alle Einzeltests den Zustand „pass“
zurückgeliefert haben.
Hinweis:
TTCN-3 liefert Beschreibungsmöglichkeiten und Methoden zur Überprüfung
von Testkonsistenz. Die letztliche Interpretation eines Testergebnisses liegt
aber in der Hand des Testdesigners.
Achten Sie stets darauf, dass bei der Beschreibung von Alternativen immer
ALLE möglichen Reaktionen erfasst werden. Ist unklar, ob überhaupt eine
Reaktion auftritt, so sollte immer mit einem Timeout eine Möglichkeit
erzwungen werden, einen Testfall zu beenden.
Das verwendete TTCN–3 Werkzeug TTWorkbench bietet die Möglichkeit, formal
korrekte, textuelle TTCN–3 Beschreibungen in grafische Darstellungen
umzuwandeln. Diese
Beim Ablauf von Tests bietet die TTWorkbench zusätzlich die Möglichkeit, den
Ablauf des Tests animiert zu visualisieren. Diese Option vereinfacht die
Interpretation des Testergebnisses. Insbesondere bei komplexen Testszenarien ist
es so vereinfacht möglich, die genauen Vor– und Randbedingungen im Fehlerfalle
zu erfassen und eine zielgerichtete Suche nach den Ursachen einzuleiten.
Implementierung von Tests in TTCN-3 41
5.8.3 Aussagekraft der Ergebnisse
Wie schon in Abschnitt 5.7 beschrieben, ist bereits beim Design eines Systems auf
die Testbarkeit zu achten. Nur wenn alle relevanten Informationen für den
Testautomaten zur Verfügung gestellt werden, kann eine korrekte Bewertung
erfolgen. So ist es z.B. in vielen Fällen prinzipiell nicht möglich, den Verlust einer
Funkverbindung zu erkennen. Wird keine kontinuierliche Funkverbindung gefordert,
so kann Ruhe im Funkkanal nicht als Kriterium gewertet werden. Sowohl der
simultane Ruhezustand aller n Teilnehmer als auch eine Situation, in der (n-1)
Teilnehmer ruhen und 1 Teilnehmer mit Batterieausfall defekt ist, liefern das gleiche
Messergebnis.
Die Aussagekraft einer Messung und damit der Bewertung eines Phänomens sind
also in hohem Maße kontextabhängig. Eine generelle Aussage, ob ein Test gut oder
schlecht ist, kann daher nicht getroffen werden. Hingegen ist es sicher möglich, die
Anzahl der unterschiedlich realisierten Testfälle zu erfassen. Ziele von Tests können
somit (mit dem Ziel des Verdicts „Passed“) z.B. sein:
1) Code Coverage Test:
Das Ziel ist, möglichst viele Passagen des Quelltexts tatsächlich zu
durchlaufen.
2) Parameter Test:
Das Ziel ist, für eine Funktion oder eine Gruppe von Funktionen die
Ausführung mit möglichst vielen Parameterkombinationen zu durchlaufen.
Auf Grund des hohen Aufwandes werden solche Tests ggfs. auf Tests am
Rande gültiger Parameterintervalle sowie Stichproben innerhalb und
außerhalb dieser Intervalle reduziert.
3) Tests von Reaktionszeiten
4) Stresstests
5) U.v.m.
Hinweis:
Eine noch so komplexe Testbeschreibung kann nicht sicherstellen, dass das
SUT ohne Fehler implementiert wurde. Hierzu wäre es unter anderem
42 Arbeitsablauf der automatisierten Entwicklung
notwendig, zu beweisen, dass das Testsystem fehlerfrei ist und wiederum,
dass der Beweis korrekt ist usw. ad infinitum.
5.9 Programmierung und Test auf dem Zielsystem
5.9.1 Verwendung des Programmiergerätes und Verkabelung
Für viele Schritte des in diesem Praktikum durchgeführten Projektes ist es
notwendig, erzeugten oder manuellen Code auf die Zielplattform zu übertragen oder
auf der Zielplattform auszuführen. Der Anschluss des Programmiergerätes an die
Zielplattform erfolgt in der in Abbildung 11 dargestellten Weise.
Quelle: Handbuch zur Hardwareplattform, Dresden–Elektronik
Abbildung 11: Anschluss der Programmiergeräts
Das Programmiergerät (D) wird über das Verbindungskabel mit dem Sensor
Terminal Board (C) verbunden. Achten Sie bei der Verbindung auf die richtige
Orientierung des Adaptersteckers, wie im Bild gezeigt. Die Stromversorgung des
Sensor Terminal Boards erfolgt über die USB Schnittstelle. Dies gilt ebenso für das
Programmiergerät, das mit einem weiteren USB Kabel gleichzeitig an der
Arbeitsstation angeschlossen wird.
Jedem Praktikumsteam stehen zur Verfügung:
a) 1 Programmiergerät
b) 2 Sensor Terminal Boards
c) 3 Funkknoten mit Batteriefach
Programmierung und Test auf dem Zielsystem 43
d) 1 USB Netzteil
e) 3 USB Kabel
5.9.2 Laden und Debuggen der erzeugten Software
Nach der erfolgreichen Erstellung von Binärcode innerhalb des in Abschnitt 3.3.2
Atmel Studio 6.0 für die Zielplattform wird der erzeugte Code beim Start der
Debugging Funktion automatisch in den Flash–Speicher der Controllers übertragen.
Die Ausführung stoppt beim Einsprung in die Funktion „main“. Nun stehen Ihnen die
folgenden Funktionen zur Verfügung:
1) Run (F5)
Das Programm wird gestartet und läuft ungehindert durch.
2) Step
Der Code der Quelltextzeile, die als Ausführungspunkt durch einen gelben
Pfeil am linken Rand markiert ist, wird ausgeführt. Handelt es sich dabei,
oder auch bei einem Teil des Ausdrucks, um einen Funktionsaufruf, so wird
dieser Aufruf und alle daraus folgenden durchlaufen, bis die Anwendung zur
nächsten Quelltextzeile zurückgekehrt ist.
3) Stepinto
Die Funktion ist analog zu „Step“, jedoch wird immer bei der nächsten
Anweisung angehalten. Dies gilt dann auch für den Einsprungspunkt der
nächsten Funktion.
4) Stepout
Innerhalb einer Funktion ist es möglich, die Ausführung zu starten, bis die
Funktion wieder verlassen wird. Die Ausführungsmarkierung ist dann im
Quelltext an dem Punkt gesetzt, bei dem Ausführung nach dem Ende der
aktuellen Funktion wieder aufgenommen wird.
Während die MCU angehalten ist, d.h. sofort nach dem Start des Debuggings oder
am Ende jeder schrittweisen Ausführung, können im Quelltext an beliebiger Stelle
so genannte „Breakpoints“ gesetzt werden. Sollte diese Funktion scheinbar nicht
möglich sein, so gibt es hierfür zwei Ursachen:
a) Die gewählte Position im Quelltext wird nie erreicht, z.B. weil ein Aufruf der
umgebenden Funktion nie erfolgt.
b) Sie haben den Quelltext verändert und im Vergleich zum geladenen Code
haben sich die Positionen (Zeilennummern) verschoben. Ist dies der Fall, so
können Sie vielleicht an untypischen Positionen (Leerzeilen, vor oder nach
der eigentlichen Funktion) Breakpoints setzten. Unterbrechen Sie in diesem
Fall, soweit notwendig, das Debugging und starten Sie, nach einer erneuten
Erzeugung des Binärcodes, neu.
c) Die Hardwareressourcen sind erschöpft und weitere Breakpoints können
nicht mehr gehandhabt werden. Löschen Sie andere, nicht mehr benötigte
Breakpoints und versuchen Sie es erneut.
Während die MCU angehalten ist, können Sie über den I/O-view auch die Bits aller
internen Register der MCU direkt verändern. So können Sie z.B. Überprüfen, ob das
Setzen oder Rücksetzten bestimmter Bits tatsächlich die geplante Funktion hat.
44 Arbeitsablauf der automatisierten Entwicklung
5.10 Verifikation, Validierung und Abschlussdokumentation
Sind alle praktischen Teile abgeschlossen, so endet jedes Projekt mit einer
Abschlussdokumentation. Stellen Sie sich hier noch einmal die beiden Fragen:
1) Haben wir alles richtig gemacht?
2) Haben wir das Richtige gemacht?
Unter der Annahme, dass Sie beide Fragen mit „Ja“ beantworten, dokumentieren
Sie dies auch nachvollziehbar in einem Abschlussdokument. Die Grundregeln für
dessen Erstellung sind:
1) Das Anforderungsdokument sollte zitiert werden.
2) Jede Anforderung aus dem Anforderungsdokuments sollte aufgenommen
und deren Erfüllung dokumentiert werden.
3) Abweichungen vom Anforderungsdokument, das sind auch zusätzlich
erreichte Ziele, müssen dokumentiert sein.
4) Zur weiteren Verwendung der Projektergebnisse müssen alle Projektdateien
gesichert und ein erfolgreicher Weg zu deren Restaurierung dokumentiert
sein.
5) Fachliche Ergebnisse sind in Form eines Datenblattes zu ergänzen.
Insbesondere Punkt 4 führt in der Praxis oft zu Problemen und damit zum Verlust
wertvollen Know–Hows. Überprüfen Sie der Restaurierungsmöglichkeit z.B. so:
a) Benennen Sie das Stammverzeichnis, in dem Sie die letzten Arbeiten
gemacht haben nach dem Beendigen aller Aktivitäten um.
b) Restaurieren Sie durch Zugriff auf ein zentrales Repository die Quelldateien
neu.
c) Starten Sie nun die Tool-Kette
d) Ist die Erzeugung der Programmierdaten auf Anhieb gelungen?
e) Falls d) positiv beantwortet wurde, vergleichen Sie das Resultat mit Ihrer
Sicherheitskopie. Sind die erzeugten Dateien gleich groß? Ist der Inhalt
offensichtlich identisch?
Haben Sie die Fragen unter e) auch noch positiv (d.h. mit „Ja“) beantwortet, so ist
das Projekt dieses Praktikums beendet.
45
6 Bedingungen für eine erfolgreiche Teilnahme
Dieser Abschnitt beschreibt die Rahmenbedingungen der Praktikumsdurchführung
mit dem Ziel, den Erfolg des Praktikums durch eine strukturierte Teamarbeit sicher
zu stellen und eine nachvollziehbare Bewertung im Einzelfall zu ermöglichen.
Grundsätzliche Arbeitsregeln
1) Die Bestätigung der erfolgreichen Teilnahme ist an zwei Bedingungen
geknüpft:
a. Regelmäßige Anwesenheit (nur bei Anwesenheit können Punkte
erworben werden.)
b. Erzielung von 75% der erreichbaren Punkte (derzeit 33) bei der
Bearbeitung der Praktikumsaufgaben.
2) Teilnehmer müssen grundsätzlich zu den Terminen sowohl vormittags als
auch nachmittags anwesend sein. Eine Verspätung um mehr als 15 Minuten
wird grundsätzlich als „Fehlend“ gewertet.
3) Bei mehr als 2 Einträgen „Fehlend“ kann keine erfolgreiche Teilnahme mehr
bescheinigt werden.
4) Im Laufe der Praktikumszeit werden Aufgaben gestellt, die entweder im
Team oder individuell zu lösen sind. Für die Aufgaben gibt es jeweils einen
Zeitrahmen und es findet eine Bewertung der erstellten Lösung statt.
5) Die Aufgaben eines Tages werden nach der Feststellung der Anwesenheit
verteilt.
6) Die Punkte werden immer pro Praktikumsteam vergeben!
Mindestanforderungen an alle Lösungen
1) Die Aufgaben müssen zum vereinbarten Termin vollständig vorliegen. Eine
iterative Überprüfung der Ergebnisse, d.h. mit zwischenzeitlichen
Korrekturen, ist nicht vorgesehen.
2) Aller Ergebnisse müssen vor der Abgabe in einem zentralen Repository
gespeichert sein. Punktabzüge können vorgenommen werden, wenn:
a. Ergebnisdateien im Repository liegen.
b. Nach einem Auschecken aus dem Repository ein typischer Ablauf des
Workflows bis zur Lösung nicht mehr möglich ist.
Bewertungskriterien der Lösungen
1) Vollständigkeit der Lösung. (alle Teilaspekte, geforderte Dokumente)
2) Sicheres Verhalten bei fehlerhaften Eingaben.
3) Erläuterung der Lösung.
4) Plausible und sachgerechte Dokumentation.
5) Erzielen der gewünschten Funktion.
47
7 Praktikumsaufgaben
7.1 Allgemeines
Die folgende Liste der Aufgaben bildet ausschließlich den geplanten, thematischen
Umfang der während des Praktikums zu lösenden Aufgaben ab. Die detaillierten
Aufgabenstellungen werden grundsätzlich zu Beginn der Sitzungen verteilt und
werden vom Timing individuell auf die Praktikumssituation zugeschnitten.
Auf Grund der spezifischen Leistungen der Praktikumsgruppen kann es somit zu
zeitlichen Verschiebungen kommen. Das dargestellte Raster ist daher nur als
Planungsgrundlage und Referenz für den Inhalt zu verstehen.
7.2 Implementierung eines einfachen UML State–Charts
7.2.1 Beispiel: Etablierung des Funknetzes (1,5h)
Aufgabe:
Implementierung eines Zustandsautomaten mit 1 Zustand, einer Ausgabe und
einer Zeitbedingung.
Ziel der Aufgabe:
Die Studierenden sollen sich mit dem Editor vertraut mache und die Fähigkeit
nachweisen, formal korrekte Eingaben entsprechend eines
Anforderungsdokuments durchzuführen und so einen realen Sachverhalt
plausibel zu modellieren.
Mindestanforderung an die Lösung:
Das State–Chart muss ohne Fehlermeldungen eingegeben sein und alle
verlangten Ein- und Ausgabesignale aufweisen. Eine Simulation des
vorgegebenen Verhaltens muss möglich bzw. Abweichungen von den
Erwartungen müssen schlüssig erklärt werden.
7.2.2 Beispiel: Modellierung des Anmeldeprozesses (2,5h)
Aufgabe:
Implementierung eines Zustandsautomaten mit mehreren Zuständen und
eigenständiger Analyse. Komplettierung der Aufgabenstellung um
Fehlerbehandlung.
Ziel der Aufgabe:
Die Studierenden simulieren komplexer Systeme mit nebenläufigen Zuständen
und experimentieren mit unterschiedlichen Lösungsansätzen. Die Aufgabe soll
die Kreativität bei der Modellbeschreibung fördern.
Mindestanforderung an die Lösung:
Das State–Chart muss ohne Fehlermeldungen eingegeben sein und alle
verlangten Ein- und Ausgabesignale aufweisen. Eine Simulation des
vorgegebenen Verhaltens muss möglich bzw. Abweichungen von den
Erwartungen müssen schlüssig erklärt werden.
48 Praktikumsaufgaben
7.3 Integration mit der Hardwareplattform
7.3.1 Arbeiten mit der Quellcodeverwaltung (0,5h)
Aufgabe:
Arbeit mit der Quellcodeverwaltung, um das Ausgangsprojekt zu erhalten und in
eine individuelle Kopie für die jeweilige Arbeitsgruppe zu überführen und die
automatische Code-Generierung zu konfigurieren.
Ziel der Aufgabe:
Die Studierenden lernen Grundlagen der effizienten Code-Verwaltung im Team
kennen. Unterscheidung von Originalquellen und erzeugten Daten. Die
Fähigkeiten zur Erzeugung reproduzierbarer Software-Revisionen werden
trainiert.
Mindestanforderung an die Lösung:
Die Arbeitsbereiche müssen funktionsfähig und aus dem zentralen Repository
restaurierbar sein.
7.3.2 Verwendung der Team–Funktionen (1h)
Aufgabe:
Ergänzung eines Code-Skeletts bis zur fehlerfreien Erzeugung eines lauffähigen
Programms und Verteilung der Lösung im Team.
Ziel der Aufgabe:
Die Studierenden sammeln erste Erfahrungen mit der Ausführungsumgebung
und üben gleichzeitig die Weitergabe gefundener Lösungen an andere
Teammitglieder.
Mindestanforderung an die Lösung:
Eine ladbare Software muss entstanden sein eindeutig aus dem Repository als
individueller Softwarestand abrufbar sein. Dies darf frühere Versionen nicht
beeinflussen.
7.3.3 Aufbau einer Ausführungsumgebung auf der Zielplattform (2h)
Aufgabe:
Komplexere Aufgabe zur Ausfüllung des Codeskeletts bis zu einem Zustand, in
dem die Ausführung generierten Codes auf der Hardware prinzipiell möglich ist.
Ziel der Aufgabe:
Der Softwarerahmen auf der Embedded Plattform wird komplettiert und die
Ausführung der weiteren Aufgaben vorbereitet. Die Studierenden sammeln
Erfahrungen im Umgang mit dem Zielsystem und erlernen die
Rahmenbedingungen für die Nutzung der Werkzeugkette.
Mindestanforderung an die Lösung:
Die implementierten Funktionen müssen compilierbar und ein vorgegebenes
Beispiel korrekt ausführbar sein.
Einführung in die Fallstudie 49
7.4 Einführung in die Fallstudie
7.4.1 Erstellung einer Demoapplikation (1,5h)
Aufgabe:
Erweiterung der Testumgebung zur Verifikation des Systemmodells. Eine
Einbettung des automatisch erzeugten Codes in einen Demonstrator im Sinne
von „Software in the Simulation–loop“ wird vorgenommen.
Ziel der Aufgabe:
Im Sinne des V–Modells wird ein Modultest erreicht, der potentiellen Anwendern
einen intuitiven Zugang zur angestrebten Lösung ermöglicht um eine frühzeitige
Validierung des Lösungskonzept zu erreichen. Es werden Erfahrungen mit der
Wiederverwendung von getestetem Code in unterschiedlichen
Laufzeitumgebungen gesammelt.
Mindestanforderung an die Lösung:
Eine Ausführung des erzeugten Codes in der „Wirt-Applikation“ mit korrekter
Funktion in Bezug auf den vorgegebenen Automaten muss erreicht werden. Die
„Fehlfunktion“ des vorgegebenen Automaten sollte erkannt werden.
7.4.2 Verbesserung des Beispiel–State–Charts (1h)
Aufgabe:
Korrektur des gegebenen Automaten bis zu einer korrekten Lösung.
Ziel der Aufgabe:
Die Ergebnisse der Validierung sollen genutzt werden um mit vergleichsweise
geringem Aufwand den entdeckten Fehler zu korrigieren.
Mindestanforderung an die Lösung:
Protokollierung der Fehlfunktion, des entwickelten Arbeitsziels, danach korrekte
Funktion des Beispiels.
7.4.3 Pflege des Anforderungsdokuments (0,5h)
Aufgabe:
Dokumentieren der Entwicklungsiteration im Anforderungsdokument.
Ziel der Aufgabe:
Der Umgang mit Projektdokumenten wird vertieft.
Mindestanforderung an die Lösung:
Formal und textuell korrekte Abbildung der Entwicklung im
Anforderungsdokument.
50 Praktikumsaufgaben
7.5 Lokale Tests auf der Hardwareplattform
7.5.1 Erstellung, Programmieren und Debugging (2h)
Aufgabe:
Erweiterung des Quellcodes für Physical Adaptation Layers auf der
Hardwareplattform zur Erfüllung aller Anforderungen der Fallstudie.
Ziel der Aufgabe:
Die Studierenden sammeln Erfahrungen mit der Abbildung von
Softwareartefakten auf physikalische Ein– und Ausgänge. Dies schließt Arbeiten
zur Verifikation der Detaillösung in Form einer Testapplikation.
Mindestanforderung an die Lösung:
Die notwendigen Tests zur Verifikation der Lösung inklusive des Debuggings auf
der Zielplattform müssen demonstriert werden.
7.5.2 Austausch des manuellen Codes gegen ein State–Chart (1h)
Aufgabe:
Eine UML Modell wird erstellt, gegen das die manuell erzeugte Testapplikation
ausgetauscht werden soll.
Ziel der Aufgabe:
Die Studierenden erlernen die Notwendigkeit der Verifikation des
Generatorprozesses im Rahmen der Qualitätssicherung des automatisierten
Entwicklungsprozesses.
Mindestanforderung an die Lösung:
Beide Lösungsvarianten, sowohl die manuelle aus Teil 7.5.1 als auch die hier
erzeugte müssen identische Funktion zeigen.
7.5.3 Einbindung der Demoapplikation in den Hardwarekontext (1h)
Aufgabe:
Übertragung der verbesserten Version der Fallstudie aus Abschnitt 7.4.2 auf die
Hardware (monolithisch).
Ziel der Aufgabe:
Die grundsätzliche Funktion aller Systemkomponenten wird im Sinne der
Verifikation des Entwicklungsprozesses nachgewiesen.
Mindestanforderung an die Lösung:
Nachweis der Funktionsfähigkeit und vollständige Pflege aller Projektdokumente.
7.6 Integration des Funknetzes (I)
7.6.1 Umsetzung einer Beispielapplikation (3h)
Aufgabe:
Die Umsetzung der kompletten Fallstudie auf ein verteiltes System wird
vorbereitet. Dazu sind die Möglichkeiten an Hand von Beispielapplikationen zu
analysieren und eine Entscheidung über das weitere Vorgehen eigenständig zu
treffen.
Integration des Funknetzes (II) 51
Ziel der Aufgabe:
Die Studierenden erlernen die Dokumentation des Projektvorgehens bei
praktischen Versuchen in der Umsetzung von Anforderungen mit gegebenen
Mitteln.
Mindestanforderung an die Lösung:
Operative Umsetzung in der Arbeitsumgebung und praktischer Nachweis, d.h.
Vorführung, der implementierten Basisfunktionalität.
7.6.2 Integration von Applikation und Funkschnittstelle (3h)
Aufgabe:
Die durch die Funkkommunikation notwendigen Zusatzfunktionen sind in das
Systemmodell aus 7.4.2 zu integrieren.
Ziel der Aufgabe:
Die Studierenden sammeln Erfahrungen mit der Wiederverwendung und
Konfiguration von Code und ergänzen selbstständig neue Funktionen.
Mindestanforderung an die Lösung:
Eine verifizierte Lösung bis zur Beschreibung eines vollständigen Arbeitsablaufs
muss vorliegen. Die gezeigten Funktionen müssen gegen die erstellten
Anforderungen validiert sein.
7.7 Integration des Funknetzes (II)
7.7.1 Tests zwischen 2 Komponenten (3h)
Aufgabe:
Die Ergebnisse aus 7.6.2 sind in die Hardwareplattform zu integrieren,
notwendige Anpassungen auf der Plattform manuell vorzunehmen, und ein
Integrationstest erfolgreich zu absolvieren.
Ziel der Aufgabe:
Die Studierenden Erlernen das Vorgehen bei Integrationstests und Methodik zur
Überprüfung von Systemschnittstellen. Dabei entsteht ein verteilt
funktionierendes System der Fallstudie.
Mindestanforderung an die Lösung:
Ein Dokumentation der Kommunikationsschnittstellen muss vorliegen und der
Funktionstest mit 2 Funkknoten erfolgreich abgeschlossen werden.
7.7.2 Integration zwischen Teams (3h)
Aufgabe:
Die Ergebnisse aus 7.7.1 sind zwischen je zwei Teams so zu integrieren, dass
ein System entsprechend der Abbildung 2 entsteht.
Ziel der Aufgabe:
Erfahrungen mit der Adaption von Schnittstellen und Test der Interoperabilität in
Form eines „Plugfest“.
Mindestanforderung an die Lösung:
Die Integration beider Teams soll erfolgreich abgeschlossen, notwendige
52 Praktikumsaufgaben
Änderungen dokumentiert und das Ergebnis aus dem Repository reproduzierbar
sein.
7.8 Erstellung von Testszenarien in TTCN-3
7.8.1 Einbindung der Demo–Applikation in den Test (2h)
Aufgabe:
Zur Automation von Tests und der Anbindung von Testwerkzeugen wird die PC–
Demoapplikation aus 7.4.1 zu einem „Beobachter“ modifiziert, der eine
abstrahierte Bewertung der State–Chart–Funktionen ermöglicht.
Ziel der Aufgabe:
Die Studierenden erarbeiten Aspekte des Testen, u.a. auch die Notwendigkeit
der Validierung von Testumgebungen.
Mindestanforderung an die Lösung:
Die Lösung sollte eine Fernsteuerung des Simulators ermöglichen und die aus
den vorherigen Tests erwarteten Ergebnisse widerspiegeln.
7.8.2 Einbindung der Hardware in die Testumgebung (1,5h)
Aufgabe:
Die Lösung aus Aufgabe 7.7.2 wird an den Testbeobachter angeschlossen.
Ziel der Aufgabe:
Die Studierenden sollen erlernen, wie „Design for Testability“ den Einsatz
automatisierter Werkzeugketten ermöglicht.
Mindestanforderung an die Lösung:
Eine Beobachtung der Zustandswechsel im Beispielsystem auf dem PC soll
möglich sein.
7.8.3 Grundlagen des automatisierten Testens (1,5h)
Aufgabe:
Es soll eine formale, tabellarisch textuelle Testbeschreibung inklusive einer
entsprechenden Ergebnisbewertung erstellt werden. Das Ergebnis ist in TTCN-3
zu formulieren und auszuführen. (Ein Beispielsystem wird modifiziert).
Ziel der Aufgabe:
Erlernen des grundsätzlichen Umgangs mit Werkzeugen zur Testdefinition
und -ausführung.
Mindestanforderung an die Lösung:
Ein plausibles Textdokument ist zu erstellen und die Funktion bzw. der
Testablauf zu demonstrieren
7.9 Qualifikation und Freigabe des Ergebnisses
7.9.1 Einbindung der Hardware in den Testablauf (2h)
Aufgabe:
Die TTCN-3 Umsetzung ist unter Nutzung der Ergebnisse aus 7.8.1 und 7.8.2
Qualifikation und Freigabe des Ergebnisses 53
sowohl mit dem State–Chart Simulator als auch mit der Hardwareumgebung zu
integrieren.
Ziel der Aufgabe:
Das Zusammenwirken aller Teile der Werkzeugkette soll integriert demonstriert
und so ein Eindruck vom Umfang der Gesamtlösung zu vermitteln.
Mindestanforderung an die Lösung:
Die Tests sollen den Durchgriff der Testumgebung auf die Implementierung der
Fallstudie zeigen.
7.9.2 Abschlussdokumentation (2h)
Aufgabe:
Die Abschlussdokumentation wird erstellt. Diese soll insbesondere den Grad der
Zielerreichung in Bezug auf das erstellte und im Praktikumsverlauf gepflegte
Anforderungsdokument darstellen.
Ziel der Aufgabe:
Die Studierenden erlernen die Übergabe der Abschlussdokumente mit der
Intension, die Ergebnisse nachweisbar und wiederverwendbar zu machen.
Mindestanforderung an die Lösung:
Formal und textuell korrekte Abbildung der Sachverhalte und vollständige Pflege
des Ergebnisses im Repository
