Master Thesis: Diplombericht Services-Framework für ein ...static.sws.bfh.ch/download/MAS-06-01-25-doc.pdf · Master Thesis: Diplombericht Services-Framework für ein Roboter Analyse

M:\Eigene Dateien\MAS-IT\05_MasterThesis\MaTh_ERATooL_Diplombericht_V2_00.doc

Master Thesis: Diplombericht

Services-Framework für ein Roboter Analyse Tool

Abstract Es soll ein Tool für die Darstellung und Editierung von Roboter Parameterdaten erstellt werden. Die Applikation soll auf einem Services-Framework aufbauen. Neue Funktionalitäten können die

Dienste des Frameworks nutzen und somit effizienter realisiert werden.

Keywords Framework, Design Pattern, .NET, Konfiguration

Allgemeine Angaben Dokument Version V2.00 Klasse Nr. MAS-06-01.25 Ort, Datum Malters, 05.09.2008

Student Peter Zurkirchen

(Erowa AG) Luzernstrasse 14, 6102 Malters 079 / 794 27 89

Betreuer

Simon Kuster (Erowa AG)

Alte Distelbergstrasse 9, 5035 Unterentfel-den

062 / 723 15 94

Experte

Prof. Urs Künzler (Software-Schule

Schweiz)

Wankdorffeldstrasse 102, 3014 Bern 032 / 321 63 43

Inhaltsverzeichnis Seite 2 / 124

Inhaltsverzeichnis 1 Allgemeines .......................................................................................................................8

1.1 Zweck des Dokuments................................................................................................8 1.2 Abgrenzung ...............................................................................................................8 1.3 Zielgruppe des Dokuments..........................................................................................8 1.4 Referenzen ................................................................................................................8

2 Analyse .............................................................................................................................9 2.1 Allgemeines ...............................................................................................................9 2.2 Übersicht ...................................................................................................................9

2.2.1 Kontext ..................................................................................................................9 2.2.2 Bestehende Umsysteme........................................................................................10

2.3 Ausführbare Aktionen mit ERATooL ...........................................................................11 2.4 Beschreibung der Use Cases .....................................................................................12

2.4.1 Use Case Modell ...................................................................................................12 2.4.2 Use Case 1100: Konfiguration darstellen ................................................................13 2.4.3 Use Case 1110: Konfiguration in Tabelle darstellen.................................................15 2.4.4 Use Case 1120: Konfiguration in Baumstruktur darstellen........................................16 2.4.5 Use Case 1200: Parameter editieren ......................................................................17 2.4.6 Use Case 1210: Parameter in Tabelle editieren.......................................................18 2.4.7 Use Case 1220: Parameter in Baumstruktur editieren..............................................21 2.4.8 Use Case 1300: Daten einlesen .............................................................................22 2.4.9 Use Case 1301: Daten verifizieren .........................................................................27 2.4.10 Use Case 1400: Daten ausgeben........................................................................28 2.4.11 Use Case 1500: Defaultparametersatz erzeugen .................................................31

2.5 Fachklassendiagramm der Applikation .......................................................................33 2.6 Grafische Benutzerschnittstelle..................................................................................34

2.6.1 Layout .................................................................................................................34 2.7 Analyse der Framework-Services ...............................................................................35

2.7.1 Logging................................................................................................................35 2.7.2 File Processing......................................................................................................36

2.8 Prototyping ..............................................................................................................42 3 Architektur und Design Pattern .........................................................................................44

3.1 Aufbau und Architektur der Software.........................................................................44 3.1.1 Namespace Übersicht ...........................................................................................44 3.1.2 Schichtenarchitektur .............................................................................................45 3.1.3 Model-View-Controller vs. Document-View Architekturmuster ..................................45

3.2 Design Pattern .........................................................................................................46 3.2.1 Observer Design Pattern .......................................................................................46 3.2.2 Singleton Design Pattern.......................................................................................46 3.2.3 FlyWeight Design Pattern ......................................................................................46

4 Design.............................................................................................................................47 4.1 Allgemeines .............................................................................................................47

4.1.1 Sprache ...............................................................................................................47 4.1.2 Präfixe .................................................................................................................47 4.1.3 Bezeichnungen .....................................................................................................47

4.2 Namespaces ............................................................................................................47 4.2.1 Namespace Detail Diagramm.................................................................................48 4.2.2 Application Namespaces........................................................................................49 4.2.3 Services-Framework Namespaces ..........................................................................65

4.3 Instanzierung der Objekte während der Startup-Phase ...............................................72 4.4 Ablaufbetrachtungen nach Benutzer-Interaktionen .....................................................74

4.4.1 Auswahl der Speicherablage des Beschreibungsfile beim Einlesen............................74 4.4.2 Auswahl der zu schreibenden Parameterfiles ..........................................................76

5 Implementation ...............................................................................................................78


5.1 Implementation der Design Pattern ...........................................................................78

5.1.1 Singleton Pattern..................................................................................................78 5.1.2 Observer Pattern mit Events..................................................................................78

5.2 CFwCsvReader und CFwCsvWriter .............................................................................81 5.3 Interaktion zwischen Controller und GUI....................................................................82 5.4 Arbeiten mit .NET Datenstrukturen............................................................................82

5.4.1 Verwendung eines Dictionary als Datenstruktur ......................................................82 5.4.2 Arbeiten mit einer DataTable.................................................................................83

5.5 Arbeiten mit XML unter .NET 2.0 ...............................................................................83 5.5.1 Einlesen des XML-Beschreibungsfile mit DOM .........................................................83 5.5.2 Traversieren im XML-Beschreibungsfile mit XPath ...................................................83

5.6 Logging mit log4net .................................................................................................84 5.6.1 Allgemeines..........................................................................................................84 5.6.2 Konfiguration von log4net .....................................................................................84

5.7 Code Dokumentation mit NDoc2005 ..........................................................................87 5.7.1 Allgemeines..........................................................................................................87 5.7.2 NDoc2005 einrichten.............................................................................................87 5.7.3 XML-Dokumentationstags......................................................................................87 5.7.4 Dokumentation mit NDoc2005 erzeugen ................................................................88

6 Testing............................................................................................................................90 6.1 Test Koordinaten......................................................................................................90

6.1.1 Zweck des Tests ...................................................................................................90 6.1.2 Testablauf............................................................................................................90 6.1.3 Test Objekt ..........................................................................................................90 6.1.4 Test Einschränkungen...........................................................................................90 6.1.5 Test Umgebung....................................................................................................90

6.2 Testsession..............................................................................................................91 6.2.1 Testsequenz 0000: Allgemeine Tests .....................................................................91 6.2.2 Testsequenz 1300: Daten einlesen ........................................................................93 6.2.3 Testsequenz 1100: Konfiguration darstellen ...........................................................95 6.2.4 Testsequenz 1200: Parameter editieren .................................................................96 6.2.5 Testsequenz 1400: Daten ausgeben ......................................................................97

6.3 Testen mit Testing-Framework NUnit 2.4.7 ................................................................98 6.3.1 Motivation ............................................................................................................98 6.3.2 Allgemeines..........................................................................................................98 6.3.3 Add-in für Visual Studio 2005 ................................................................................99 6.3.4 Umsetzung...........................................................................................................99

7 Besprechung.................................................................................................................. 102 7.1 Allgemeines ........................................................................................................... 102

7.1.1 Priorität.............................................................................................................. 102 7.1.2 Status ................................................................................................................ 102

7.2 Abweichungen vom Pflichtenheft............................................................................. 102 7.3 Status der Anforderungen basierend aus dem Pflichtenheft....................................... 103

7.3.1 Applikation ......................................................................................................... 103 7.3.2 Services-Framework............................................................................................ 106 7.3.3 Produkt-Qualität ................................................................................................. 108 7.3.4 Prozess-Qualität ................................................................................................. 110

8 Projekt .......................................................................................................................... 111 8.1 Projekt Ablauf ........................................................................................................ 111

8.1.1 Meetings mit dem Experten................................................................................. 111 8.1.2 Projekt Hilfsmittel ............................................................................................... 113

8.2 Reflexion ............................................................................................................... 115 9 Literatur- und Medienverzeichnis..................................................................................... 117

9.1 Literaturverzeichnis ................................................................................................ 117 9.2 Web-Links.............................................................................................................. 118


10 Anhang ..................................................................................................................... 120

10.1 Übersetzung der Englischen Begriffe ab Design........................................................ 120 10.2 Anpassungen der Sourcen von NDoc2005................................................................ 121

Dokument History Seite 5 / 124

Abbildungsverzeichnis Abbildung 1: Kontext-Diagramm mit ERATooL und Umsystemen..................................................9 Abbildung 2: Mögliche Aktivitäten mit ERATooL ........................................................................11 Abbildung 3: Use Case Diagramm............................................................................................12 Abbildung 4: Aktivitätsdiagramm zu UC 1100 Konfiguration darstellen .......................................14 Abbildung 5: Aktivitätsdiagramm zu UC 1210 Parameter in Tabelle editieren ..............................20 Abbildung 6: Workflow Daten einlesen .....................................................................................25 Abbildung 7: Aktivitätsdiagramm zu UC 1300 Daten einlesen.....................................................26 Abbildung 8: Workflow Daten ausgeben...................................................................................29 Abbildung 9: Aktivitätsdiagramm zu UC 1400 Daten ausgeben...................................................30 Abbildung 10: Aktivitätsdiagramm zu UC 1500 Defaultparametersatz erzeugen...........................32 Abbildung 11: Fachklassendiagramm der Applikation ................................................................33 Abbildung 12: Grobes Layout der ERATooL Benutzerschnittstelle ...............................................34 Abbildung 13: Daten Workflow: Schnittstellen Applikation - Framework......................................36 Abbildung 14: Parameterfile im binären Format ........................................................................37 Abbildung 15: Parameterfile im ASCII Format ...........................................................................37 Abbildung 16: Header und Body des Parameter Beschreibungsfiles ............................................39 Abbildung 17: Strukturbeschreibung einer Parametergruppe .....................................................40 Abbildung 18: Beschreibung eines Parameters..........................................................................41 Abbildung 19: GUI des Prototyp „Prototyp01“...........................................................................43 Abbildung 20: Übersicht der Namespaces von ERATooL ............................................................44 Abbildung 21: Schichtenmodell ................................................................................................45 Abbildung 22: Namespace Detail Diagramm der ERATooL Applikation ........................................48 Abbildung 23: ApController Klassendiagramm...........................................................................50 Abbildung 24: ApGUI Klassendiagramm ...................................................................................55 Abbildung 25: Aufbau des ERATooL MainWindow .....................................................................56 Abbildung 26: Message Box für eine Benutzer Information ........................................................57 Abbildung 27: Message Box für eine Benutzer Warnung............................................................57 Abbildung 28: About Dialog .....................................................................................................58 Abbildung 29: Location Dialog für das Einlesen der Parameterfiles .............................................58 Abbildung 30: Location Dialog für das Ausgeben der Parameterfiles...........................................59 Abbildung 31: Parameterfile Export Auswahl Dialog ..................................................................59 Abbildung 32: Darstellung der Konfiguration als Tabelle in DataGridView ...................................60 Abbildung 33: Parameter Detail Darstellung..............................................................................61 Abbildung 34: Parameter Detail Dialog mit Drop-Down Auswahlliste ..........................................62 Abbildung 35: Parameter Detail Dialog mit numerischem Eingabefeld ........................................62 Abbildung 36: Parameter Detail Dialog mit schreibgeschütztem Eingabefeld ...............................62 Abbildung 37: ApManagement Klassendiagramm ......................................................................63 Abbildung 38: ApDefinitions Klassendiagramm..........................................................................64 Abbildung 39: FwLogger Klassendiagramm...............................................................................65 Abbildung 40: FwDefinitions Klassendiagramm .........................................................................66 Abbildung 41: FwFileProcessor Klassendiagramm......................................................................68 Abbildung 42: FwDataRepository Klassendiagramm ..................................................................70 Abbildung 43: Sequenzdiagramm während Startup-Phase .........................................................72 Abbildung 44: Objektdiagramm nach Startup-Phase..................................................................73 Abbildung 45: Sequenzdiagramm bei der Selektion des Speicherorts beim Einlesen ....................74 Abbildung 46: Sequenzdiagramm für die Auswahl der zu schreibenden Parameterfiles ................76 Abbildung 47: Codeschnipsel der Singleton Implementation in C# .............................................78 Abbildung 48: Aufbau und Struktur des Event Handling.............................................................79 Abbildung 49: Sequenzdiagramm: Installation der EventHandler................................................80 Abbildung 50: Sequenzdiagramm: Benachrichtigung der Datenänderung ...................................81 Abbildung 51: Verwendung eines Dictionary als Datenstruktur...................................................82 Abbildung 52: Arbeiten mit der Datenstruktur DataTable in .NET ...............................................83 Abbildung 53: Konfiguration für Logging auf die Konsole...........................................................85

Dokument History Seite 6 / 124

Abbildung 54: Konfiguration für Logging in ein File ...................................................................86 Abbildung 55: Anlegen der Rollup Backup Logging Files ............................................................86 Abbildung 56: Konfiguration für die Deaktivierung des Loggings ................................................86 Abbildung 57: NDoc2005 GUI zum Erstellen der Code Dokumentation .......................................88 Abbildung 58: Code-Dokumentation in der HTML Web-Darstellung ............................................89 Abbildung 59: Code-Dokumentation in der CHM-Helpfile ...........................................................89 Abbildung 60: GUI des Testing Framework NUnit......................................................................98 Abbildung 61: Starten der Tests aus der Entwicklungsumgebung VS2005...................................99 Abbildung 62: Bedeutung und Verwendung der NUnit Test Tags ............................................. 100 Abbildung 63: ERATooL Projektplan ....................................................................................... 112 Abbildung 64: Management Cockpit mit Auflistung der Zeitaufwände....................................... 113

Allgemeines Seite 7 / 124

Dokument History Datum Version Beschreibung Autor

29.04.2008 1.00 Dokument erstellt / Grobe Struktur des Dokuments auf-gesetzt / Use Case Diagramme und Beschreibungen er-stellt / Ablaufdiagramme erstellt / sonstige Analysegrafi-ken erstellt / Applikationsfachklassen-Diagramm erstellt / Logger Funktionalität beschrieben / File Handling be-schrieben.

PZU

22.05.2008 1.10 Beginn der Dokumentation des Designs. PZU 26.05.08 1.20 Version 1.20 für Meeting mit Herrn Prof. Künzler erstellt PZU 11.06.08 1.22 Beginn der Beschreibung der Code-Dokumentation im

Implementations-Kapitel. PZU

02.07.08 1.30 Basieren auf V1.22 habe ich nochmals ein neues Word-Dokument eröffnet. Habe nun begonnen die Diagramme und Grafiken für das definitive Design einzufügen.

PZU

09.08.08 1.40 Nach der Fertigstellung der SW soll nun der Diplombe-richt definitiv fertig gestellt werden.

PZU

11.08.08 1.41 Die Beschreibung der Use Cases ist nun definitiv abge-schlossen. Das Analyse Kapitel ist mit dieser Version fer-tig dokumentiert worden.

PZU

12.08.08 1.42 Das Architektur-Kapitel ist fertig überarbeitet. PZU 14.08.08 1.43 Habe begonnen das Design-Kapitel zu erstellen. PZU 16.08.08 1.44 Weiterarbeit am Design-Kapitel. PZU 17.08.08 1.45 Fertigstellung der Applikation und Framework Namespace

Beschreibung im Design-Kapitel. PZU

17.08.08 1.46 Weitere Designbetrachtungen. PZU 19.08.08 1.50 Weiterarbeit an Design-, Implementation- und Testkapi-

tel PZU

19.08.08 1.51 Design Kapitel fertig gestellt. Implementationskapitel bis auf die Beschreibung vom CsvReader und CsvWriter fer-tig. Testingkapitel begonnen. Diese wurde Herrn Prof. Künzler am 19.08.08 für das Meeting vom 21.08.08 zu-gesendet.

PZU

23.08.08 1.60 Fertigstellung des Implementations- und Testing Kapitel. Dieser Stand wurde zur Korrektur verteilt.

PZU

26.08.08 1.61 Erstellung des Besprechungs-Kapitels und Durchführung der Abnahme gemäss Anforderungsliste und Testing.

PZU

30.08.08 1.71 Anpassung des Diplomberichts anhand der Korrekturen. PZU

Analyse Seite 8 / 124

1 Allgemeines In diesem Dokument wird die Durchführung der Master Thesis des MAS Information Technology Studiengangs beschrieben. Nebst technischen Abhandlungen (Analyse und Design) sind auch ad-ministrative Aspekte (Projektdurchführung) zur ausgeführten Arbeit erläutert. Das Kernstück der Master Thesis ist die Analyse und das Design der Anwendung, welche ausführ-lich mit Text und Bild (Use Case Beschreibung, Ablaufdiagramme UML) erläutert sind. Im Kapi-tel Architektur wird der Aufbau und die Struktur der Software diskutiert. Das Implementations-Kapitel beschreibt, wie konkrete Designentscheidungen umgesetzt bzw. ein-gesetzt wurden. Im Testing-Kapitel werden aus Zeitgründen nur die Standard-Abläufe (Schönwet-terfälle) abgehandelt. Im Kapitel Besprechung werden die dokumentierten Anforderungen des Pflichtenhefts mit den effektiv realisierten Anforderungen der Software gegenüber gestellt und Abweichungen zum Pflich-tenheft dokumentiert. Das Kapitel Projekt beschreibt einige Aspekte zur Planung und Durchführung der Master Thesis. Zudem wird die realisierte Arbeit noch einmal kritisch durchleuchtet (Reflexion). Im Anhang befin-den sich diverse Zusätze, welche zur Vollständigkeit der Arbeit beitragen.

1.1 Zweck des Dokuments Das Dokument soll Einsicht in die realisierten Arbeiten und Ergebnisse der Master Thesis liefern. Der Diplombericht ist ein wesentlicher Bestandteil der Master Thesis und wird für die Beurteilung der Master Thesis herangezogen.

1.2 Abgrenzung Der Diplombericht basiert auf den Ausführungen des Pflichtenhefts. Um Redundanzen zu vermei-den, werden Aspekte des Pflichtenhefts nicht noch einmal erläutert sondern darauf referenziert.

1.3 Zielgruppe des Dokuments Der Inhalt dieses Dokuments richtet sich in erster Linie an folgende Personen:

• Experte: Prof. Urs Künzler (SWS) • Betreuer: Simon Kuster (EROWA AG) • Student: Peter Zurkirchen (EROWA AG)

Zudem spricht der Bericht diejenigen Personengruppen an, welche sich mit den Themengebieten .NET und objektorientierte Analyse und Design auseinander setzen. Für das Verständnis des In-halts sind teilweise Kenntnisse der objektorientierten Softwareentwicklung und der Notationsspra-che UML erforderlich.

1.4 Referenzen Ein Verweis auf die aufgeführten Referenzen wird wie folgt realisiert [ID der Referenz]. Zum Bei-spiel Verweis auf Referenz 2 siehe [Dok_02].

ID Referenz Version Autor01 MaTh_ERATooL_Pflichtenheft_1_50.pdf 1.50 PZU 02 MaTh_Glossar_ERATooL_V1_10.pdf 1.10 PZU


2 Analyse

2.1 Allgemeines Wie aus dem Pflichtenheft1 ersichtlich ist, besteht ERATooL aus einer Applikation und einem Servi-ces-Framework. Nachfolgend werde ich zuerst die Applikation (basierend auf Use Cases) und da-nach das Services Framework beschreiben. Die textlichen Ausführungen sind mit UML-Diagrammen und Grafiken erweitert, um die Nachvollzieh- und Realisierbarkeit zu erleichtern.

2.2 Übersicht

2.2.1 Kontext

Als erstes soll mit der Abbildung 1 eine Übersicht aller beteiligten Systeme aufgezeigt werden. Zu-dem ist ersichtlich, wie die zu entwickelnde ERATooL Applikation im Kontext mit den heute beste-henden Umsystemen (Grafik stammt aus Pflichtenheft) eingebettet werden soll.

Abbildung 1: Kontext-Diagramm mit ERATooL und Umsystemen

1 Siehe [Dok_01]


2.2.2 Bestehende Umsysteme

Erowa Testsuite Wie aus Abbildung 1 ersichtlich ist, sind das Erobi-Tool1, das Logging-Tool und der FTP-Client be-stehende Applikationen der Erowa Testsuite. Diese Applikationen dienen einerseits zu Test- (ERobi

simuliert Prozessleitsystem auf Protokoll Ebene) und andererseits zu Wartungs-Zwecken (Log-ging-Tool Aufzeichnen der Tätigkeiten des Roboters / FTP-Client Datenaustausch über FTP zwischen Roboter und PC). Excel Die MS Excel Applikation wird für die Darstellung und Editierung der Roboter Parameterfiles ver-wendet. Handbediengerät Auch über das Handbediengerät kann die Parametrierung eingesehen und editiert werden. Dies kann jedoch nur für jeden Parameter einzeln ausgeführt werden. Web-Browser Über einen Web-Browser kann der Benutzer diverse Status des Roboters einsehen oder andere Tätigkeiten ausführen. Dies sind zum Beispiel:

• Einsehen der Zustände der Ein- und Ausgänge • Einsehen der Status der Futter und Greifer bezüglich der Werkstückbeladung • Download von Allgemeinen- und Parameterbeschreibungs-Dokumente im PDF-Format • …

Roboter-Daten Partitionen Das Robotersystem besitzt zwei Partitionen, über welche mit einem FTP-Client Files transferiert werden können:

• Die Dokument-Partition beinhaltet alle Files bezüglich der Dokumentation (Allgemeine- und Parameterbeschreibungs-Files im PDF-Format) und der Web-Darstellung (Startseite in-dex.html, Icons, Grafiken usw.).

• Die Parameter-Partition beinhaltet die Parameterfile im binären (Datei-Endung *.bin) und ASCII-Format (Datei-Endung *.da). Die Parameterfiles im binären Format werden von der Roboter Steuerung verwendet. Der Benutzer kann über das Handbediengerät aus den binären Parameterfiles ASCII Parameterfiles erzeugen.

1 Siehe Glossar [Dok_03]

Analyse

Seite 11 / 124

2.3 Ausführbare Aktionen mit ERATooL Wie aus Abbildung 2 zu entnehmen ist, können mit ERATooL diverse Aktivitäten durchgeführt wer-den. Grundsätzlich sind dies folgende:

• Daten einlesen • Parameter darstellen • Parameter editieren • Daten ausgeben • Defaultparametersatz erzeugen

Abbildung 2: Mögliche Aktivitäten mit ERATooL

Die ausführbaren Aktionen werden als Use Cases modelliert. Diese sind textlich beschrieben und graphisch mit Ablaufdiagrammen visualisiert worden.


Abbildung 3: Use Case Diagramm

2.4 Beschreibung der Use Cases

2.4.1 Use Case Modell

Analyse

Seite 13 / 124

2.4.2 Use Case 1100: Konfiguration darstellen

2.4.2.1 Use Case Beschreibung

Use Case: Konfiguration darstellen Name Konfiguration darstellen ID UC_1100_Konfiguration_darstellen Beschreibung Der Anwender kann eine Parametergruppe (z. B. Achsen, Futter,

Greifer) einer eingelesenen Konfiguration anhand der verfügbaren Darstellungsmöglichkeiten entweder tabellarisch oder in einer Baumstruktur darstellen.

Beteiligte Personen-gruppen

• Service-Techniker • Montage-Techniker

Rolle der Personen-gruppen

• Anwender

Benötigte Artefakte Je nachdem, welche Darstellung der Anwender wünscht, müssen Parameterfiles und das Beschreibungsfile verfügbar sein

Auslöser Der Anwender will die Konfiguration eines Roboter-Systems dar-stellen.

Standard Ablauf Standard Vorbedin-gung

Die gewünschten Files konnten erfolgreich eingelesen werden und sind im Übersichtsfenster aufgeführt.

Nr Wer Was 1 Anwender selektiert im Übersichtsfenster die gewünschte Karteikarte 2 Anwender selektiert in der Karteikarte die gewünschte Komponente (Parametergrup-

pe oder Parameter), welche dargestellt werden soll 3 System stellt selektierte Komponente (Parametergruppe oder Parameter) in einem

separaten Fenster dar Standard Nachbedin-gung

Keine


Abbildung 4: Aktivitätsdiagramm zu UC 1100 Konfiguration darstellen

2.4.2.2 Aktivitätsdiagramm


2.4.3 Use Case 1110: Konfiguration in Tabelle darstellen


Use Case: Konfiguration in Tabelle darstellen Name Konfiguration in Tabelle darstellen ID UC_1110_Konfiguration_in_Tabelle_darstellen Beschreibung Der Anwender kann eine Parametergruppe (z. B. Achsen, Futter,

Greifer) einer eingelesen Konfiguration tabellarisch darstellen. Beteiligte Personen-gruppen



• Anwender

Benötigte Artefakte Für die tabellarische Darstellung der Konfiguration müssen fol-gende Artefakte zwingend verfügbar sein: • 1..10 Parameterfiles

Auslöser Der Anwender will die Konfiguration eines Roboter-Systems tabel-

larisch darstellen. Die tabellarische Darstellung zeigt alle Parame-ter einer Parametergruppe mit deren Werten in einer Tabelle.


Die gewünschten Parameterfile(s) konnten erfolgreich eingele-sen werden und sind im Übersichtsfenster aufgeführt.

Nr Wer Was 1 Anwender selektiert im Übersichtsfenster die „File-Browser“ Karteikarte 2 Anwender selektiert in der „File-Browser“ Karteikarte die gewünschte Parametergrup-

pe, welche dargestellt werden soll 3 System stellt selektierte Parametergruppe in einem separaten Fenster tabellarisch

dar Standard Nachbedin-gung

Keine


2.4.4 Use Case 1120: Konfiguration in Baumstruktur darstellen


Use Case: Konfiguration in Baumstruktur darstellen Name Konfiguration in Baumstruktur darstellen ID UC_1120_Konfiguration_in_Baumstruktur_darstellen Beschreibung Der Anwender kann eine Parametergruppe (z. B. Achsen, Futter,

Greifer) einer eingelesen Konfiguration in einer Baumstruktur dar-stellen.




• Anwender

Benötigte Artefakte Für die tabellarische Darstellung der Konfiguration müssen fol-gende Artefakte zwingend verfügbar sein: • 1..10 Parameterfiles • Beschreibungsfile

Auslöser Der Anwender will detaillierte Informationen zu einem Parameter

erhalten. Standard Ablauf Standard Vorbedin-gung

Die gewünschten Parameterfile(s) und das Beschreibungsfi-le konnten erfolgreich eingelesen werden und sind im Übersichts-fenster aufgeführt.

Nr Wer Was 1 Anwender selektiert im Übersichtsfenster die „Group-Browser“ Karteikarte 2 Anwender selektiert in der „Group-Browser“ Karteikarte den gewünschten Parameter,

zu welchem er mehr Informationen haben will 3 System stellt den selektierten Parameter in einem separaten Fenster mit allen ver-

fügbaren Angaben dar Standard Nachbedin-gung

Keine


2.4.5 Use Case 1200: Parameter editieren


Use Case: Parameter editieren Name Parameter editieren ID UC_1200_Parameter_editieren Beschreibung Der Anwender kann eine vom System dargestellte Konfiguration

editieren. Je nachdem, welche Darstellungsart der Anwender ausgewählt hat, kann eine bestehende Konfiguration in tabellari-scher oder in Baumstruktur editiert werden.




• Anwender

Benötigte Artefakte Für die Editierung müssen folgende Artefakte zwingend verfügbar sein: • 1..10 Parameterfiles • Beschreibungsfile für Darstellung der Konfiguration in Baum-

struktur

Auslöser Der Anwender will eine eingelesene und dargestellte Konfigurati-on editieren.


Die gewünschten Files konnten erfolgreich eingelesen und darge-stellt werden.

Nr Wer Was 1 Anwender selektiert den gewünschten Parameterwert, welcher editiert werden will 2 Anwender gibt den neuen Parameterwert ein 3 System prüft Parameterwert auf dessen Gültigkeit 4 System übernimmt den neuen Parameterwert Standard Nachbedin-gung

Keine


2.4.6 Use Case 1210: Parameter in Tabelle editieren


Use Case: Parameter in Tabelle editieren Name Parameter in Tabelle editieren ID UC_1210_Parameter_in_Tabelle_editieren Beschreibung Der Anwender kann eine tabellarisch dargestellte Konfiguration

editieren. In der tabellarischen Darstellung sind alle Parameter der Parametergruppe dargestellt.



Rolle der Personengrup-pen

• Anwender

Benötigte Artefakte Für die Editierung der gesamten Konfiguration müssen fol-gende Artefakte zwingend verfügbar sein: • 1..10 Parameterfiles

Auslöser Der Anwender will eine eingelesene und dargestellte Konfigura-

tion in tabellarischer Form editieren. Standard Ablauf Standard Vorbedingung Die Parameterfile(s) konnten erfolgreich eingelesen und darge-

stellt werden. Nr Wer Was 1 Anwender selektiert den gewünschten Parameterwert, welcher editiert werden will. 2 Anwender gibt den neuen Parameterwert ein 3 Anwender schliesst die Eingabe ab (Enter-Taste oder selektieren einer neuen Zelle) 4 System prüft Parameterwert auf dessen Gültigkeit <<include>>

UC_1301_Daten_verifizieren5 System übernimmt den neuen Parameterwert Standard Nachbedin-gung

Keine

Alternativer Ablauf a.) Der Anwender will einen bereits editierten Parameterwert nicht übernehmen Alternative Vorbedin-gung a.)

Die Parameterfiles und das Beschreibungsfile konnten erfolg-reich eingelesen und dargestellt werden.

Nr Wer Was 1 - 2 Standard Ablauf 3a Anwender drückt die „Esc“-Taste, um die Eingabe nicht zu übernehmen 4a System übernimmt den neuen Parameterwert nicht Alternative Nachbedin-gung a.)

Keine


Alternativer Ablauf b.) Der Anwender will einen Parameter editieren, welcher schreibgeschützt ist Alternative Vorbedin-gung b.)

Die Parameterfiles und das Beschreibungsfile konnten erfolgreich eingelesen und dargestellt werden.

Nr Wer Was 1 - 4 Standard Ablauf 5b System informiert den Anwender mit einer Meldungsbox, dass der Parameter-

wert nicht editiert werden kann 6b Anwender bestätigt die Meldung mit dem Button „OK“ 7b System übernimmt den neuen Parameterwert nicht Alternative Nachbe-dingung b.)

Keine

Alternativer Ablauf c.) Der Anwender ändert einen Parameterwert, welcher ausserhalb des gültigen Wertebereichs liegt Alternative Vorbedin-gung c.)


Nr Wer Was 1 - 4 Standard Ablauf 5c System informiert den Anwender mit einer Meldungsbox, dass der editierte Pa-

rameterwert ausserhalb des Wertebereichs liegt 6c Anwender bestätigt die Meldung mit dem Button „OK“ 7c System übernimmt den neuen Parameterwert nicht Alternative Nachbe-dingung c.)

Keine

Alternativer Ablauf d.) Der Anwender editiert einen Parameterwert mit einer ungültigen Eingabe (z. B. alphanumerische statt numerische Eingabe) Alternative Vorbedin-gung d.)


Nr Wer Was 1 - 4 Standard Ablauf 5d System informiert den Anwender mit einer Meldungsbox, dass der Parameter-

wert nicht gültig ist 6d Anwender bestätigt die Meldung mit dem Button „OK“ 7d System übernimmt den neuen Parameterwert nicht Alternative Nachbe-dingung d.)

Keine



Abbildung 5: Aktivitätsdiagramm zu UC 1210 Parameter in Tabelle editieren


2.4.7 Use Case 1220: Parameter in Baumstruktur editieren


Use Case: Parameter in Baumstruktur editieren Name Parameter in Baumstruktur editieren ID UC_1220_Parameter_in_Baumstruktur_editieren Beschreibung Der Anwender kann eine, in einer Baumstruktur dargestellte Kon-

figuration editieren. Bei der Darstellung der Parameter in der Baumstruktur wird ein einzelner Parameter mit Detail-Informationen aufgelistet. Bevor ein Parameterwert editiert wird, setzt sich die Applikation den Eingabebereich und ein allfälliger Schreibschutz des Parameters. Die Eingabefelder sind so ausge-legt, dass Falscheingaben ausgeschlossen sind.




• Anwender

Benötigte Artefakte Für die Editierung der gesamten Konfiguration müssen fol-gende Artefakte zwingend verfügbar sein: • 1..10 Parameterfiles • das Beschreibungsfile muss auch eingelesen werden, sonst

kann die Darstellung der Parameter in der Baumstruktur gar nicht angezeigt werden

Auslöser Der Anwender will eine eingelesene und dargestellte Konfigurati-

on editieren. Bei der Editierung der Konfiguration in der Baum-struktur erhält der Benutzer detaillierte Angaben zum gewünsch-ten Parameter, welcher editiert werden will.


Die Parameterfile(s) und das Beschreibungsfile konnten erfolg-reich eingelesen und dargestellt werden.

Nr Wer Was 1 Anwender selektiert den gewünschten Parameterwert, welcher editiert werden will 2 Anwender gibt den neuen Parameterwert ein (Drop-Down Liste oder numerisches

Eingabefeld) 3 Anwender schliesst die Eingabe ab (Enter-Taste oder selektieren eines neuen Parame-

ters) 4 System übernimmt den neuen Parameterwert Standard Nachbedin-gung

Keine


2.4.8 Use Case 1300: Daten einlesen


Use Case: Daten einlesen Name Daten einlesen ID UC_1300_Daten_einlesen Beschreibung Der Anwender kann das Beschreibungsfile und Parameterfiles selek-

tieren, welche nachfolgend in ERATooL eingelesen werden. Bevor die Daten eingelesen werden, müssen diese zuerst validiert werden. Erst bei erfolgreicher Prüfung werden die Daten in interne Struktu-ren gespeichert.




• Anwender

Benötigte Artefakte Der Anwender kann ein Parameterfile bis zur gesamten Konfigurati-on von 10 Parameterfiles einlesen. Sofern ein Beschreibungsfile vorhanden ist, kann dieses vom An-wender eingelesen werden.

Auslöser Der Anwender will Parameter- und dazugehörige Beschreibungs-files in ERATooL einlesen.


Ein gültiges Beschreibungsfile und gültige Parameterfile(s) liegen vor. Der Anwender will diese von einem Laufwerk aus einlesen.

Nr Wer Was 1 Anwender selektiert den Menüpunkt „Öffnen…“ 2 System erzeugt einen Dialog, um die physikalische Datenablage auszuwählen, von

wo das Beschreibungsfile eingelesen werden kann (von der Roboter-Steuerung via FTP3, von einem Laufwerk (lokal / remote) oder ob kein Be-schreibungsfile eingelesen werden soll).

3 Anwender selektiert physikalische Datenablage und drückt auf den Button „Weiter“ 4 System erzeugt File-Browser um das Beschreibungsfile auswählen zu können 5 Anwender selektiert das Beschreibungsfile und drückt auf den Button „Öffnen“ 6 System verifiziert den Header des Beschreibungsfile auf dessen Gültigkeit

<<include>> UC_1301_Daten_verifizieren7 System erzeugt einen Dialog, um die physikalische Datenablage auszuwählen, von

wo Parameterfiles eingelesen werden können (von der Roboter-Steuerung via FTP4, von einem Laufwerk (lokal / remote) oder ob kein File eingelesen werden soll).

8 Anwender selektiert physikalische Datenablage und drückt auf den Button „Weiter“ 9 System erzeugt File-Browser um Parameterfiles auswählen zu können 10 Anwender selektiert die Parameterfile(s) und drückt auf den Button „Öffnen“ 11 System verifiziert die Header der Parameterfiles auf dessen Gültigkeit

<<include>> UC_1301_Daten_verifizieren12 System liest Daten des Beschreibungsfiles ein 13 System verifiziert gelesenen Daten

<<include>> UC_1301_Daten_verifizieren14 System schreibt gelesenen Daten in interne Strukturen

3 Dieses Feature besitzt lediglich die Priorität 3 und wird je nach zeitlichem Verlauf realisiert 4 Dieses Feature besitzt lediglich die Priorität 3 und wird je nach zeitlichem Verlauf realisiert


15 System liest Daten der Parameterfiles ein 16 System verifiziert gelesene Daten <<include>>

UC_1301_Daten_verifizieren17 System schreibt gelesene Daten in interne Strukturen 18 System informiert Anwender über das erfolgreiche Einlesen der Daten 19 Anwender bestätigt die gezeigten Informationen bezüglich des Einlesevorgangs mit

„OK“ 20 System zeigt eingelesene Daten im Übersichtsfenster an Standard Nachbedin-gung

Die gewünschten Files konnten vom System erfolgreich eingelesen werden

Alternativer Ablauf a.) Der Anwender will nur das Beschreibungsfile einlesen Alternative Vorbe-dingung a.)

Ein gültiges Beschreibungsfiles liegt vor. Der Anwender will dies von einem Laufwerk aus einlesen.

Nr Wer Was 1 - 7 Standard Ablauf 8a Anwender selektiert keine Datenquelle und drückt auf den Button „OK“ 12 - 14 Standard Ablauf 18 - 20 Standard Ablauf Alternative Nachbe-dingung a.)

Das System hat nur das Beschreibungsfile eingelesen

Alternativer Ablauf b.) Der Anwender will nur Parameterfiles einlesen Alternative Vorbe-dingung b.)

Es liegen gültige Parameterfiles vor. Der Anwender will diese von einem Laufwerk aus einlesen.

Nr Wer Was 1 - 2 Standard Ablauf 3b Anwender selektiert keine Datenquelle und drückt auf den Button „Weiter“ 7 - 11 Standard Ablauf 15 - 20 Standard Ablauf Alternative Nachbe-dingung b.)

Es wurden nur die Parameterfiles eingelesen

Alternativer Ablauf c.) Der Header des Beschreibungsfiles ist ungültig Alternative Vorbe-dingung c.)

Ein Beschreibungsfile liegt vor. Der Anwender will diese von einem Laufwerk aus einlesen.

Nr Wer Was 1 - 6 Standard Ablauf 7c1 System informiert den Anwender, dass der Header des Beschreibungsfiles

ungültig ist 7c2 Anwender quittiert die Meldung mit dem Button „OK“ 7c3 System informiert den Anwender, dass der Einlesevorgang nicht erfolgreich

abgeschlossen werden konnte 7c4 Anwender beendet den Einlesevorgang mit dem Button „OK“ Alternative Nachbe-dingung c.)

System hat keine Beschreibungs- oder Parameterfiles eingelesen

Alternativer Ablauf d.) Mindestens ein Header eines Parameterfiles ist ungültig Alternative Vorbe-dingung d.)

Es liegen Parameterfiles vor. Der Anwender will diese von einem Laufwerk aus einlesen.

Nr Wer Was 1 - 11 Standard Ablauf 12d1 System informiert den Anwender, dass mindestens ein Header der Parame-

terfile(s) ungültig ist


12d2 Anwender quittiert die Meldung mit dem Button „OK“ 12d3 System informiert den Anwender, das der Einlesevorgang nicht erfolgreich

abgeschlossen werden konnte 12d4 Anwender beendet den Einlesevorgang mit dem Button „OK“ Alternative Nachbe-dingung d.)

System hat keine Beschreibungs- oder Parameterfiles eingelesen

Alternativer Ablauf e.) Die Version des Beschreibungsfiles passt mit mindestens einer Version eines Parameterfiles nicht überein Alternative Vorbe-dingung e.)

Es liegen Parameterfiles und ein Beschreibungsfile vor, welche un-tereinander verschiedene Versionen enthalten.

Nr Wer Was 1 - 11 Standard Ablauf 12e1 System informiert den Anwender, dass die Version des Beschreibungsfiles

nicht mit den Versionen der Parameterfiles übereinstimmt 12e2 Anwender quittiert die Meldung mit dem Button „OK“ 12e3 System informiert den Anwender, dass der Einlesevorgang nicht erfolgreich

abgeschlossen werden konnte 12e4 Anwender beendet den Einlesevorgang mit dem Button „OK“ Alternative Nachbe-dingung e.)

System hat keine Beschreibungs- oder Parameterfiles eingelesen.

Alternativer Ablauf f.) Der Body des Beschreibungsfiles ist fehlerhaft Alternative Vorbe-dingung f.)

Ein Beschreibungsfile liegt vor. Der Anwender will diese von einem Laufwerk aus einlesen.

Nr Wer Was 1 - 13 Standard Ablauf 14f1 System informiert den Anwender über die ungültige Stelle im Beschrei-

bungsfile 14f2 Anwender quittiert die Meldung mit dem Button „OK“ 14f3 System informiert den Anwender, dass der Einlesevorgang nicht erfolgreich

abgeschlossen werden konnte 14f4 Anwender beendet den Einlesevorgang mit dem Button „OK“ Alternative Nachbe-dingung f.)


Alternativer Ablauf g.) Der Body mindestens eines Parameterfiles ist fehlerhaft Alternative Vorbe-dingung g.)

Es liegen Parameterfiles vor. Der Anwender will diese von einem Laufwerk aus einlesen.

Nr Wer Was 1 - 17 Standard Ablauf 18g1 System informiert den Anwender, dass der Body eines Parameterfiles un-

gültig ist 18g2 Anwender quittiert die Meldung mit dem Button „OK“ 18g3 System informiert den Anwender, dass der Einlesevorgang nicht erfolgreich

abgeschlossen werden konnte 18g4 Anwender beendet den Einlesevorgang mit dem Button „OK“ Alternative Nachbe-dingung g.)



Abbildung 6 zeigt den Workflow, welcher beim einlesen der Daten durchlaufen wird. Dieser ist je-doch nur schematisch dargestellt.

Abbildung 6: Workflow Daten einlesen



Abbildung 7: Aktivitätsdiagramm zu UC 1300 Daten einlesen


2.4.9 Use Case 1301: Daten verifizieren


Use Case: Daten verifizieren Name Daten verifizieren ID UC_1301_Daten_verifizieren Beschreibung Jedes Mal, wenn Daten in ERATooL eingelesen oder geändert wer-

den, muss ERATooL diese zuerst prüfen. Dieser Use Case hat die Aufgabe, die Daten zu prüfen. Beispielsweise werden beim Einlesen grundsätzliche Eigenschaften (File-Version, Name) des File-Header und File-Body auf dessen Gül-tigkeit verifiziert. Auch beim Editieren von Werten dürfen nur Änderungen akzeptiert werden, welche auch innerhalb der gesetzten Limiten geändert wur-den.

Beteiligte Perso-nengruppen

• Keine Das System führt die Verifikation durch


• Keine Das System führt die Verifikation durch

Benötigte Artefakte Die zu verifizierenden Daten können einerseits aus dem Beschrei-bungsfile oder andererseits aus den Parameterfiles stammen.

Auslöser Eine Datenänderung (einlesen, editieren) führt zu einer Verifikation der Änderungen.


Keine

Nr Wer Was 1 System liest Daten 2 System verifiziert gelesene Daten Standard Nachbe-dingung

Die einzulesenden Daten sind verifiziert und werden als gültig oder ungültig deklariert.


2.4.10 Use Case 1400: Daten ausgeben


Use Case: Daten ausgeben Name Daten ausgeben ID UC_1400_Daten_ausgeben Beschreibung Der Anwender will eine bestehende Konfiguration in ERATooL in Pa-

rameterfiles schreiben. Die Daten werden in ASCII-Files im CSV-Format5 geschrieben. Die erzeugten Parameterfiles können danach von der Roboter-Steuerung eingelesen werden. Beachte: Es werden nur Parameterfiles erzeugt. Ein Parameterbeschreibungs-file kann vom System nicht erzeugt werden.




• Anwender

Benötigte Artefakte Keine Auslöser Der Anwender will eine bestehende Konfiguration in ERATooL in Pa-

rameterfiles schreiben. Standard Ablauf Standard Vorbedin-gung

Eine gültige Konfiguration ist in ERATooL eingelesen.

Nr Wer Was 1 Anwender selektiert den Menüpunkt „Speichern…“ 2 System erzeugt einen Dialog, um die Parametergruppen zu selektieren, welche

nachfolgend in ASCII-Files geschrieben werden sollen 3 Anwender selektiert gewünschte Parametergruppe(n) und drückt auf den Button

„Weiter“ 4 System erzeugt einen Dialog, um die physikalische Datenablage auszuwählen, auf

welchem die Parameterfiles abgelegt werden sollen (auf einem Laufwerk (lokal oder remote) oder auf der Roboter-Steuerung via FTP6)

5 Anwender selektiert physikalische Datenablage und drückt auf den Button „Weiter“ 6 System erzeugt File-Browser, um Speicherort auswählen zu können 7 Anwender selektiert den gewünschten Speicherort und drückt auf den Button „OK“ 8 System schreibt Konfiguration aus internen Strukturen in Parameterfiles 9 System informiert Anwender über das erfolgreiche Schreiben der Daten 10 Anwender bestätigt die Meldung und drückt auf den Button „OK“ Standard Nachbe-dingung

Die gewünschte Konfiguration ist in Parameterfile(s) abgelegt

5 Siehe Glossar [Dok_02] 6 Dieses Feature besitzt lediglich die Priorität 3 und wird je nach zeitlichem Verlauf realisiert


Abbildung 8 zeigt den Workflow, welcher beim ausgeben der Daten durchlaufen wird. Dieser ist jedoch nur schematisch dargestellt.

Abbildung 8: Workflow Daten ausgeben



Abbildung 9: Aktivitätsdiagramm zu UC 1400 Daten ausgeben


2.4.11 Use Case 1500: Defaultparametersatz erzeugen


Use Case: Defaultparametersatz erzeugen Name Defaultparametersatz erzeugen ID UC_1500_Defaultparametersatz_erzeugen Beschreibung Der Anwender will ein Robotersystem von Grund auf neu konfigurie-

ren. Dazu muss er zuerst einen Defaultparametersatz generieren. Als Defaultparametersatz werden alle Parameterfiles (alle 10 Para-meterfiles) bezeichnet, welche Parameterwerte gemäss vordefinier-ten Defaultwerten besitzen. Der Anwender kann ein einzelnes Defaultparameterfile, mehrere oder ein kompletter Defaultparametersatz (besteht aus allen 10 Pa-rameterfiles) erzeugen. Der erzeugte Defaultparametersatz kann nachfolgend editiert werden.




• Anwender

Benötigte Artefakte Das Erzeugen eines Defaultparametersatzes kann nur mit Hilfe des Parameter-Beschreibungsfiles erfolgen, da nur dieses die benötigten Defaultwerte beinhaltet.

Auslöser Der Anwender will ein Robotersystem von Grund auf neu konfigurie-ren und will deshalb einen Defaultparametersatz erzeugen. Zudem kann er auch für eine einzelne Parametergruppe Defaultwerte la-den.


Das Beschreibungsfile muss erfolgreich eingelesen worden sein.

Nr Wer Was 1 Anwender selektiert den Menüpunkt „Neu…“ 2 System erzeugt Auswahl-Dialog, damit selektiert werden kann, welche Defaultpa-

rametersätze7 erzeugt werden wollen 3 Anwender wählt die gewünschten Parametergruppe(n)8 aus, um daraus Defaultpara-

metersätze erzeugen zu können. Nach der Auswahl wird der Button „Wei-ter“ gedrückt

4 System erzeugt einen File-Browser Dialog um den Speicherort auswählen zu kön-nen

5 Anwender selektiert den gewünschten Speicherort und drückt auf den Button „OK“. 6 System erzeugt ausgewählte Defaultparametersätze und zeigt diese im Übersichts-

fenster an 7 System informiert Anwender über das erfolgreiche Generieren der Defaultparame-

tersätze 8 Anwender bestätigt die Information mit dem Button „OK“ Standard Nachbe-dingung

Die gewünschten Defaultfiles wurden erzeugt

7 Siehe Parametergruppen im Glossar [Dok_02] 8 Siehe Parametergruppen im Glossar [Dok_02]

Analyse

Seite 32 / 124


Abbildung 10: Aktivitätsdiagramm zu UC 1500 Defaultparametersatz erzeugen


Abbildung 11: Fachklassendiagramm der Applikation

Das Fachklassendiagramm der Applikation zeigt die fachlich motivierten Klassen, welche Begriffe aus dem Problembereich des zu entwickelnden Systems repräsentieren. Diese sind Bestandteile des Analysemodells.

2.5 Fachklassendiagramm der Applikation


2.6 Grafische Benutzerschnittstelle

2.6.1 Layout

Das Layout des ERATooL-Hauptfensters wird neben der Menü- und Statuszeile in 2 Hauptfenster aufgegliedert:

• Overview Window • Main Window

Menüzeile

Overview Window

Main Window

Statuszeile

Abbildung 12: Grobes Layout der ERATooL Benutzerschnittstelle

2.6.1.1 Menüzeile

Die Menüzeile beinhaltet Standard Menüpunkte („Datei“, „Speichern“ usw.) und Tool-Strip Menüs. Mit diesen erfolgt die Steuerung der gewünschten Aktivitäten in ERATooL.

2.6.1.2 Statuszeile

Die Statuszeile soll generelle Information zur selektierten Komponente im Main Window anzeigen. Als generelle Informationen gelten der Handling Typ, die Version der Komponente und der Stand-ort des Cursors.

2.6.1.3 Overview Window

Das Overview Window soll als Tab-Control (Registerkarten) aufgebaut werden. Ein Tab soll die eingelesenen Files (Parameterfiles, Beschreibung) anzeigen. Ein weiterer Tab soll die eingelesene Konfiguration in XML-Darstellung anzeigen. Somit soll dieses Fenster einen Überblick der eingelesenen und dargestellten Daten darstellen.

2.6.1.4 Main Window

Das Main Window zeigt die Auflistung der im Overview Window selektierten Komponente. Je nach dem wird die Konfiguration komplett als Tabelle (ähnlich wie in Excel) oder pro Parameter als De-tail-Parameterdarstellung dargestellt. Bei der Detail-Parameterdarstellung werden die einzelnen Informationen mit graphischen Elemen-ten aufgelistet. Die detaillierten Informationen werden aus dem Beschreibungsfile ausgelesen. Dies muss somit für diese Darstellungsart eingelesen worden sein.


2.7 Analyse der Framework-Services

2.7.1 Logging

Das Logging soll während der Entwicklung und im Betrieb von ERATooL als Diagnosemittel dienen, um Abläufe in der Software als Ereignisprotokoll aufzuzeichnen. Später dient es im Betrieb zum Aufzeichnen von Fehlabläufen, welche analysiert und somit einfach behoben werden können.

2.7.1.1 Prinzipieller Aufbau eines Logging Eintrags

Datum_Zeit_Log-Level_Log-Ereignis Datum Tag.Monat.Jahr DD.MM.YYYY: Bsp. 27.07.1978 Zeit Stunden:Minute Bsp. 23:02 Log-Level

Wird geloggt bei eingestelltem Log-Level Level Info Warning Error Fatal Info x x x x

Warning x x x Error x x Fatal x OFF

Anstieg des Log-Volumen

Schweregrad des Log-Eintrags

Log-Ereignis Ein beliebiges Ereignis, welches einerseits statischer Text und andererseits Platzhalter für dynami-sche Einträge erlaubt Bsp. Framework started up Beispiel-Eintrag 12.05.2008 15:30 FW INFO: Framework started successfully up

2.7.1.2 Logging-Konfiguration

Die Einstellungen des Loggers werden in einem XML-Konfigurationsfile gespeichert. Beim Aufstar-ten wird das Logging-Verhalten anhand des eingelesenen Konfigurationsfiles konfiguriert. Es wird nur lesend auf das Konfigurationsfile zugegriffen. D. h. im Betrieb werden keine Konfigurations-Daten ins File geschrieben.

2.7.1.3 Logging Devices

Die Ausgabe des Loggings soll vom Benutzer einerseits in ein File (Tool-Einsatz) und andererseits auf die Ausgabe-Konsole (Debugging, Entwicklung) geleitet werden können. Zudem soll das Log-ging auch ausgeschaltet werden können.


2.7.2 File Processing

Das File Processing soll grundsätzlich folgende Services zur Verfügung stellen: • Parsen der Parameterfiles (Header und Body) • Einlesen des Parameterfiles und Weitergabe der Daten an die Applikation • Erzeugen von Parameterfiles aus Daten der Applikation • Parsen der Parameter Beschreibungsfiles (Header und Body) • Einlesen des Parameter Beschreibungsfiles und Weitergabe der Daten an die Applikation

Abbildung 13 zeigt die schematischen Schnittstellen zwischen der Applikation, welche ein File ein- bzw. auslesen will, und dem Services-Framework, welches die Funktionalitäten für das File Hand-ling zur Verfügung stellen soll.

Abbildung 13: Daten Workflow: Schnittstellen Applikation - Framework


2.7.2.1 Parameterfiles

Allgemeines Die Konfiguration eines Roboter Systems sind in 10 Parameterfiles ausgelagert, welche bestehend vorliegen (Datei-Endung *.dat). Diese sind im binären Format auf einem Speicher auf der Roboter-Steuerung abgelegt. Abbildung 14 zeigt einen Ausschnitt eines Parameterfiles im binären Format.

Abbildung 14: Parameterfile im binären Format

Wie aus Abbildung 14 ersichtlich ist, ist die binäre Darstellung der Parameter für die Steuerung optimal, jedoch für den Menschen unleserlich. Aus diesem Grund bietet der Roboter eine beste-hende Funktionalität, welche die binär dargestellten Parameter in Files in ASCII Darstellung ins CSV-Format9 umwandeln kann. Erst die Umwandlung in ASCII-leserliche Files bietet ERATooL den Zugang zu den Parameterfiles.

Abbildung 15: Parameterfile im ASCII Format

Header

Body

Es gilt zu beachten, dass Parametrierungen von speziellen Funktionalitäten durchaus auch Parame-terfile übergreifend vorgenommen werden muss. Die Parameterfiles liegen bereits vor und werden entweder vom Roboter oder der Entwicklungs-Simulationsumgebung erzeugt. ASCII Parameterfile Aufbau Ein Parameterfile besteht aus einem Kopf (Header) und einem Körper (Body) siehe Abbildung 15. Alle aufgeführten Werte sind mit einem Tabulator voneinander getrennt (CSV-Format). Der Header hat folgende Attribute in Klammern sind die in Abbildung 15 dargestellten Werte aufgeführt: 1. Zeile:

• Parameterfile Name (axis) • Anzahl aufgeführte Zeilen im Parameterfile (70) • Roboterbezeichnung (ERS) • Roboter Software-Version mit welcher das Parameterfile erzeugt wurde (SW V4.80)

9 Siehe Glossar [Dok_02]


• Hardware ID des Roboters (2)

2. Zeile:

• Beschriftung für die Daten des Bodys Der Body hat folgende Attribute

• Parameternummer • Adressierung (wie Index, Typ, Gruppe je nach Parameterstruktur kann diese mehrere

Adressierungselemente besitzen) • Minimaler Wert • Maximaler Wert • Parameter Wert • Kurzer Beschreibungstext

Parameterfile Entitäten Eine komplette Konfiguration eines Roboters basierend auf der RobotPlattform10 besteht aus fol-genden 10 Parameterfiles:

• AxesConfig.dat beinhaltet alle Angaben zur Konfiguration der Antriebe • ChuckConfig.dat beinhaltet alle Angaben zur Konfiguration der Futter, welche die Pa-

letten spannen • GeneralConfig.dat beinhaltet alle Angaben für generelle Einstellung des Roboters • GripperConfig.dat beinhaltet alle Angaben zur Konfiguration der Roboter Greifer, wel-

che die Paletten greifen • InterfaceConfig.dat beinhaltet alle Angaben zur Konfiguration der Schnittstellen zwi-

schen dem Roboter und Fremdsystemen (Werkzeugmaschinen oder Leitsystemen) • MachinetoolConfig.dat beinhaltet alle Angaben zur Konfiguration zwischen der Ma-

schine und dem Roboter (Prozesssicherheits-Signale11) • MagazineConfig.dat beinhaltet alle Angaben zur Konfiguration der Magazine, in wel-

chem die Paletten wie in einem Speicher abgelegt sind • PathConfig.dat beinhaltet alle Angaben zur Konfiguration der Fahrwege. Ein Fahrweg

beschreibt alle Aktivitäten (Koordinaten im Raum, Manipulationen von Greifer und Futter usw.), welche bei einer Be- oder Entladung einer Werkzeugmaschine vom Roboter ausge-führt werden müssen

• PeripheryConfig.dat beinhaltet alle Angaben zur Konfiguration eines peripheren Gerä-tes wie einer Beladestation oder Messmaschine

• Workprogram.dat beinhaltet alle Angaben zur Konfiguration eines speziellen Schnitt-stellen-Protokolls, welches den Workflow für die Be- und Entladungen definiert. Das Workprogramm ist im eigentlichen Sinne gar kein Parameterfile.

Ein Parameterfile soll zeilenweise gelesen werden. Der Zeilenabschluss ist mit Carriage Return (0xD) + Line Feed (0xA) gekennzeichnet.

10 Siehe Glossar [Dok_03] 11 Siehe Glossar [Dok_03]


2.7.2.2 Beschreibungsfile

Um der Forderung der Aktualität von ERATooL bezüglich der häufigen Parameter Änderungen ge-recht zu werden, habe ich mich entschieden, ein Parameter-Beschreibungsfile zu erstellen. Das Beschreibungsfile soll basierend auf einer XML-Filestruktur aufgebaut sein (Datei-Endung *.xml) und beinhaltet alle Informationen zur Parametrierung einer spezifischen Software Version des Ro-boters. D. h. pro Roboter Software Version und Gerät wird ein spezifischen Beschreibungsfile er-zeugt. Dieses beinhaltet alle, für dieses Gerät und Version, benötigten Informationen. Die eingelesenen Parameterdaten werden mit den Informationen des Beschreibungsfile angerei-chert und ergeben so eine umfangreiche Darstellung jedes einzelnen Parameters. Diese Informati-onen sollen den Anwender bei der Darstellung und Editierung der Konfiguration unterstützen. Nachfolgend wird beispielhaft die Beschreibung von der Parametergruppe bis zu einem Parameter aufgeführt. Aufbau von Header und Body des Beschreibungsfiles

Abbildung 16: Header und Body des Parameter Beschreibungsfiles

2.)

1.)

Beschreibung zur Abbildung 16 1.) Die erste (XML-Prolog) und zweite Zeile werden als Header (Kopf) des XML-Beschreibungsfiles bezeichnet. Diese beinhalten generelle Einträge wie XML-Version, Sprachkodex, File- und Handling-typ, Software Version usw. Vor dem Einlesen der Daten wird der Header auf dessen Gültigkeit ge-prüft. 2.) Der restliche untere Teil wird als Body (Körper) bezeichnet. Der Body ist weiter in Gruppen wie „Achsen“, „Futter“ oder „Greifer“ unterteilt. Diese sind wiederum in weitere Strukturelemente auf-geteilt.


Abbildung 17: Strukturbeschreibung einer Parametergruppe

4.)

3.)

2.)1.)

Beschreibung zur Abbildung 17 1.) Jede Parametergruppe beginnt mit dem klein geschriebenen Namen der Gruppe. 2.) Die nächste Zeile beinhaltet die Strukturbeschreibung der Parametergruppe. D. h. wie ist die Adressierung mit Set-, Index-, Type- und Parameter-Nummer aufgebaut und wie viele Entitäten gibt es davon. 3.) Nachfolgend werden die Strukturelemente (wie z. b. <SET>) mit der Nummer und dem Namen des Elements versehen. Im oben gezeigten Beispiel steht hinter dem der Set-Nummer 6 das Futter 6. 4.) Im Anschluss an die Strukturelemente werden die Beschreibungen der Parameter aufgelistet. Jede Parameter Definition beginnt mit dem Element Name <PARA>, der Parameternummer und des Parameternamens. Beachte: Eigentlich ist die Nummer des Elements (z. B. <SET Number = „03“ …> redundant, da diese implizit mit der Auflistung innerhalb des XML-Files eruiert werden kann. In der Praxis ist es jedoch viel einfacher und effizienter, das gesuchte Element direkt mit der Num-mer zu adressieren. Deshalb habe ich mich entschieden, die Nummer als Attribut zu versehen.


Abbildung 18: Beschreibung eines Parameters

7.)6.)

5.)

4.)3.)2.)

1.)

Beschreibung zur Abbildung 18 1.) Das Element <PARA> bezeichnet den Start einer Parameterbeschreibung. Neben der Nummer des Parameters wird auch dessen Bezeichnung als Attribut aufgeführt. Die Bezeichnung PARA ent-spricht der Kolonnen-Bezeichnung im Parameterfile. Somit kann direkt mit der Kolonnenbezeich-nung im Beschreibungsfile nach dem Parameter gesucht werden. 2.) Das Element <Description> beinhaltet einen Text-Knoten für die erweiterte Beschreibung des Parameters. Mit dem Doppel-Slash „//“ wird dem Beschreibungs-Textfeld der Applikation sig-nalisiert, dass eine neue Zeile eingefügt werden soll. 3.) Das Element <Limits> beinhaltet die Attribute für den minimalen und maximalen Wertebe-reich des Parameters. 4.) Das Element <Default> enthält die Informationen über den Defaultwert des Parameters. 5.) Das Element <ValueDescription> enthält einen möglichen Wert und dessen textliche Be-schreibung, welche der Parameter einnehmen kann. 6.) Das Element <Image> bezeichnet den Namen des dazugehörigen Bildes, welches in der De-taildarstellung angezeigt wird. 7.) Das Element <Dependency> enthält die Verknüpfung als Parameter-Nummer zu anderen Pa-rametern, welche mit diesem in Beziehung stehen. Dieses Element muss nicht zwingend vorhan-den sein.


2.8 Prototyping Da ich in der GUI-Programmierung und der .NET Umgebung keine grosse Erfahrung vorweisen kann, habe ich vor und während der Design Phase diverse Technology-Prototypen erstellt. Diese wurden natürlich „quick and dirty“ d. h. ohne grosse Kommentare und Designvorgaben erstellt. Die Prototypen waren der Schlüssel zur erfolgreichen Implementierung von ERATooL. Das „Look and Feel“ mit .NET und dem Visual Studio 2005 konnte sehr effektiv und gezielt ausprobiert wer-den. Durch die Erfahrungen der kleinen Programme konnten wichtige Design-Entscheide gefällt werden. Folgende Technologie-Prototypen wurden erstellt:

Prototyp Zweck Documentor Um das .NET Dokumentationstool NDoc einzusetzen, habe ich

zuerst eine kleine Beispiel-Applikation mit den Dokumentations-Tag implementiert.

log4NetConsoleApplication Das Logging ist eine Komponente, welche das Services Frame-work zur Verfügung stellen muss. Nach einigen Recherchen bin ich im Internet auf das Apache log4net Logging Framework gestossen. Die Konfiguration des Loggers (XML-Konfigurationsfile) und dessen Verwendung konnte mit diesem Prototyp geübt werden.

ParseParameterFile Um ERATooL mit Daten zu speisen, müssen zuerst die Parame-terfiles in ERATooL eingelesen werden. Bevor ich selber einen Parser geschrieben habe, googelte ich im Netz. Schon nach kurzer Zeit bin ich im Netz auf einen fast fixfertigen Csv-Reader und -Writer gestossen. Mit wenig Anpassungsauf-wand konnte ich den Reader und Writer einsetzen. Um die Funktionalität der beiden Komponenten zu demonstrie-ren, habe ich diese Prototypen erstellt.

FillUpTreeView Wie erstelle und fülle ich das GUI Elemente TreeView ab? Die-ses graphische Element wird als File und Group- Browser in ERATooL eingesetzt. Für das „Look and Feel“ habe ich mit die-sem GUI Element gespielt.

EventHandlerExample Damit ich das Observer Pattern umsetzen konnte, musste die Verwendung eines EventHandlers angeeignet werden. Dieser Prototyp wurde für die ersten Versuche mit EventHandlern ver-wendet.

PrototypRessourceList Um die Bilder im Parameter Detail-Dialog darzustellen, wollte ich eine Ressource-Liste einsetzen. Dieser kleine Technologie-Prototyp wurde für die Verwendung der Ressource Liste er-stellt.

WindowsForms Um die Verwendung von verschiedenen graphischen Elementen kennen zu lernen (TreeView, UserControl, Panel …), wurde dieser Prototyp erstellt

Prototyp01 Der Prototyp01 war der grösste und abschliessende Prototyp. Er vereinte die oben aufgeführten kleineren Prototypen zu ei-ner Applikation, welche im Grundsatz der zu entwickelnden ERATooL Applikation sehr nahe stand.


Wie aus den oben aufgeführten Ausführungen ersichtlich ist, haben sich die Prototypen gelohnt. Nach der Implementierung des Prototyp01 hatte ich genug Erfahrung, um die Design-Phase in Angriff zu nehmen.

Abbildung 19: GUI des Prototyp „Prototyp01“

Zeigt die graphische Oberfläche von PrototypV1, mit welcher folgende Aktionen ausgeführt werden konnten:

• Einlesen eines Parameterfiles • Einlesen eines XML-Beschreibungsfiles • Darstellen der Werte des eingelesenen Parameterfiles in einer Tabelle mit DataGridView • Darstellen der Konfiguration als XML-Baum mit Beschriftungen aus dem XML-

Beschreibungsfile • Selektieren eines Elements im Group Tree View und Darstellung im Parameter Detail View

Architektur Seite 44 / 124

3 Architektur und Design Pattern

3.1 Aufbau und Architektur der Software ERATooL ist mit dem Services-Framework und der darauf aufbauenden Applikation als Schichte-narchitektur aufgebaut. Die einzelnen Klassen sind aufgrund ihrer Funktionalität in Namespa-ces12 zusammengefasst worden. Als Grundarchitektur habe ich das Model-View-Controller13 (MVC) Konzept gewählt, welches bei Anwendungen mit Benutzungsoberflächen häufig verwendet wird und sich dafür bestens eignet.

3.1.1 Namespace Übersicht

Abbildung 20: Übersicht der Namespaces von ERATooL

In Abbildung 20 sind die Namespaces mit den groben Interaktionsrichtungen aufgeführt. Es ist klar ersichtlich, dass nur die Applikation auf das Services-Framework zugreift, nicht aber das Frame-work auf die Applikation. Dies ist sehr wichtig, da sonst die Kapselung der Schichtenarchitektur verletzt würde.

12 Ansammlungen von zusammengehörigen Klassen, welche sich im gleichen Namensraum befinden 13 Siehe [MVC]


3.1.2 Schichtenarchitektur

ERATooL ist auf einer 2-Schicht Architektur aufgebaut. Eine obere Schicht setzt auf einer unteren Schicht auf.

Abbildung 21: Schichtenmodell

Die oberhalb liegende Applikation greift mit synchronen Methodenaufrufen auf das darunter lie-gende Services-Framework zu. Im Gegensatz dazu darf das Services-Framework keine direkten Aufrufe auf Komponenten der Applikationsschicht vornehmen. Die Entkopplung zwischen dem Services-Framework und der Applikation basiert auf der Übertra-gung von asynchronen Meldungen. Es gilt jedoch zu beachten, dass die Mehrheit der Aufrufe syn-chron, von der Applikation auf das Framework, ausgeführt werden. Bei einer Mehrschicht-Architektur werden einzelne Aspekte des Softwaresystems konzeptionell einer Schicht (engl. tier oder layer) zugeordnet. Die „höher angesiedelte“ Applikation beinhaltet die Business-Logik und ist spezifisch auf die Anwendung ausgerichtet. Das „tiefer liegende“ Services-Framework ist generisch aufgebaut und stellt der Applikation Grunddienste zur Verfügung. Beachte: Die erlaubten Abhängigkeitsbeziehungen zwischen den Aspekten werden bei einer Schichtenarchi-tektur dahingehend eingeschränkt, dass Aspekte einer höheren Schicht nur solche tieferer Schich-ten verwenden dürfen.

3.1.3 Model-View-Controller14 vs. Document-View15 Architekturmuster

Für die Strukturierung der Applikation werde ich das Architekturmuster Model-View-Controller (MVC) einsetzen. Dieses eignet sich hervorragend für die Strukturierung interaktiver Systeme, wie dies bei ERATooL der Fall ist. Ein ähnlicher Ansatz verfolgt das Document-View Architekturmuster, in welchem jedoch die View mit dem Controller als eine Einheit vereint wird. Bei interaktiven Systemen ist das GUI mit der Steuerung eng verbunden und somit macht es oft Sinn, diese beiden Funktionalitäten zu einer Komponente zu vereinen. Programmiertechnisch ist die Document-View Architektur einfacher zu realisieren (einfachere Zugriffe, keine Kapselung). Durch die fehlende Kapselung zwischen View und Controller wird der Code unübersichtlicher und bei späteren Softwareerweiterungen (neues GUI…) kann dies zu er-heblichen Änderungen führen. Aus diesen Gründen werde ich das MVC-Architekturmuster einset-zen und eine saubere Trennung zwischen Visualisierung, Steuerung und Daten vornehmen.

14 Siehe [MVC] 15 Siehe [Document-View]


3.2 Design Pattern

3.2.1 Observer Design Pattern16

Änderungen der Daten (Modell) sollen an alle interessierenden Instanzen weitergeleitet werden. Das Modell soll sich jedoch nicht darum kümmern, wer an den Änderungen seiner Daten interes-siert ist. Dies kann elegant mit dem Observer Design Pattern implementiert werden. In .NET wird dies mit Delegates und Events realisiert. D. h. ein interessierendes Objekt (Observer) registriert auf dem zu beobachtenden Objekt (Obser-vable) über den Eventhandler eine Methode, welche beim Auftreten des definierten Events aufge-rufen werden soll.

3.2.2 Singleton Design Pattern17

Das Singleton Design Pattern wird dann verwendet, wenn verhindert werden soll, dass von einer Klasse mehr als ein Objekt erzeugt werden soll. Dieses Einzelstück ist darüber hinaus üblicherweise global verfügbar. Dies kann z. B. für Manager-Klassen verwendet werden, welche für das Aufstarten, die Konfigura-tion und den geordneten Zugriff seiner Objekte verantwortlich sind. Es darf jedoch nur ein Objekt pro Manager-Klasse erzeugt werden. Um dies zu garantieren, kann das Singleton Design Pattern eingesetzt werden. Ich werde dieses Design Pattern verwenden, um die Hauptobjekte wie MainController, MainView und DataRepository nur einmal erzeugen zu können. Andernfalls wird ein Laufzeitfehler ausgege-ben.

3.2.3 FlyWeight Design Pattern18

Das Flyweight Design Pattern wird verwendet, wenn eine große Anzahl von Objekten benötigt wird, die sich bestimmte variable Informationen teilen und eine herkömmliche Implementierung unverhältnismässig viele Ressourcen erfordern würde. Dies soll in ERATooL ansatzweise verwendet werden, damit die Beschreibung pro Parameter Nummer nur einmal abgelegt werden muss. Während der Analyse hat sich gezeigt, dass die Parameterbeschreibung in ein XML-Beschreibungsfile verpackt wird. Bei Bedarf wird die Parameterbeschreibung ausgelesen und direkt mit dem dazugehörigen Parameter vereint dargestellt. Somit kann der Ressourcenaufwand mini-miert werden und die Beschreibung pro Parameter muss nur einmal abgelegt werden.

16 Siehe [Observer] 17 Siehe [Singleton] 18 Siehe [Flyweight]

Design

Seite 47 / 124

4 Design

4.1 Allgemeines

4.1.1 Sprache

Die Begriffe im nachfolgenden Design und der Implementation werden in Englischer Sprache ab-gehalten. Im Anhang werden die wichtigsten Deutschen Begriffe, wie sie im Pflichtenheft und in der Analyse verwendet wurden, den Englischen gegenübergestellt.

4.1.2 Präfixe

Wie aus dem Architektur Kapitel ersichtlich ist, wird ERATooL mit einer 2-Schicht Architektur reali-siert. Alle Komponenten der Applikation erhalten den Präfix Ap und alle Komponenten des Servi-ces-Framework erhalten den Präfix Fw. Somit ist sofort ersichtlich, wo die Komponente anzuglie-dern ist. Zudem werden eigene Typen mit Präfixen bezeichnet:

• C für Klasse • I für Interface • E für Enumeration • S für Struktur • m_ für Attribute • grBox für Group Box (GUI) • btn für Button (GUI) • rdBtn für Radio Button (GUI) • lb für Label (GUI)

4.1.3 Bezeichnungen

• Konstanten und Aufzählungen in Enumerationen werden in GROSSBUCHSTABEN geschrie-ben.

• Methoden- und Attribut-Namen beginnen klein • Um die Leserlichkeit der Methoden- und Attribut-Namen zu erhöhen, wird Camel-Writing19

eingesetzt

4.2 Namespaces Wie aus Abbildung 22 ersichtlich ist, besteht die Applikation wie auch das Framework aus 4 Na-mespaces. Die Namespaces sind in logische Funktionalitäts-Einheiten unterteilt. Unter anderen gibt es ein Controller-, ein GUI-Namespace (Applikation) und ein Repository-Namespace (Framework), welche das eingesetzte MVC-Pattern20 widerspiegeln. Zudem sind weite-re Namespaces für Services und Definitionen vorhanden.

19 Camel-Writing: mehrere Worte werden als eine Bezeichnung in Kleinschrift dargestellt. Beginnt ein neues Wort innerhalb der Bezeichnung, wird der Anfangsbuchstabe gross geschrieben: Bsp: istResultatKorrekt() 20 Siehe [MVC]

Design Seite 48 / 124

Abbildung 22: Namespace Detail Diagramm der ERATooL Applikation

4.2.1 Namespace Detail Diagramm

Design

Seite 49 / 124

4.2.2 Application Namespaces

4.2.2.1 Namespace „ApController“

Namespace Beschreibung Das Applikations-Namespace ApController nimmt für die ERATooL-Applikation eine zentrale Steue-rungsfunktion ein. Einerseits kontrolliert und steuert es alle Abläufe in ERATooL und andererseits regelt es den Zugriff auf das Modell im Services-Framework. Alle Ereignisse (Benutzer-Interaktionen, System-Ereignisse) werden vom Controller-Namespace aufgenommen und gemäss dem aktuellen Zustand an die auszuführenden Stellen weitergeleitet. Die Abarbeitung kann einerseits von internen Controller-Komponenten oder an externe Komponen-ten wie dem GUI oder dem Modell übernommen werden.


Abbildung 23: ApController Klassendiagramm

Klassendiagramm


Klasse CApMainController Die Klasse CApMainController ist die Haupt-Statusmaschine. Alle auftretenden Ereignisse werden von dieser Klasse an ihre Controller-Helferklassen weitergeleitet. Als Controller-Helferklassen gel-ten folgende Klassen:

• CApHandleController: Alle Haupt Use Cases werden als eigene Klasse abgebildet und mit dem Postfix „Handler“ bezeichnet. Der CapHandleController erzeugt diese und ist für die Abwicklung der Use Ca-ses zuständig.

• CApWindowController Alle Zugriffe vom Controller auf das GUI-Namespace werden vom CApWindowController ausgeführt. Es war mir wichtig, klare Schnittstellen zwischen den Namespaces zu definie-ren. Vor allem der Zugriff vom Controller zum GUI soll zentral nur über eine Schnittstelle verlaufen. Somit ist ein Austausch des GUI-Namespaces einfach und ohne grossen Auf-wand möglich.

• CapModelController Ähnlich dem CApWindowController über nimmt der CApModelController die Aufgabe, den Controller gegenüber dem Repository (Modell) und vor allem der Framework-Schicht zu kapseln. D. h. alle Zugriffe innerhalb des Controllers auf Services im Framework laufen über den ModelController. Somit existiert auch hier eine zentrale Schnittstelle für die Zugriffe vom Controller auf das Framework. Als Ausnahme gelten die Zugriffe auf den Logger und Definitionen im Framework, welche von allen Klassen der Applikation ausgeführt werden können.

Der CApMainController besitzt die drei Controller-Klassen als Attribute und erzeugt diese beim Star-tup der ERATooL Applikation. Klasse CApHandleController Besitzt alle Handler als Attribute und erzeugt diese beim Startup der ERATooL Applikation. Alle Haupt Use Cases werden separat in einer Klasse abgehandelt, welche vom CApHandleController verwaltet werden. Klassen, welche einen Haupt Use Case abhandeln, werden mit dem Postfix „Handle“ bezeichnet. Bei Erweiterungen von neuen Use Cases werden die Funktionalitäten als Klasse zusammengefasst und vom CApHandleController verwaltet. Zudem besitzt die Klasse eine Referenz auf die abstrakte Basis-Klasse aller Handler. Dies dient dazu, polymorph auf Funktionalitäten der konkreten Handler-Klassen zuzugreifen, ohne diese direkt anzusprechen. Klasse CApBaseHandler Die abstrakte Klasse ist die Basis aller Handler-Klassen. Der CApBaseHandler definiert einige abs-trakte Methoden, welche von abgeleiteten Handler-Klassen implementiert werden müssen, um nicht selber als abstrakt zu gelten. Es sind dies die Folgenden: public abstract void performAction(object obj) protected abstract void handleStateMachine() protected abstract void handleFinish() protected abstract void initializeStates()


Beachte für alle Handler-Klassen: Die Abfolge der auszuführenden Tätigkeiten sind in kleine Teilschritte zerlegt und als Statusma-schine implementiert worden. Somit sind die Teilschritte klar ersichtlich und Änderungen bzw. Er-weiterungen einfach möglich. Die Benachrichtigung des Benutzers über den Ablauf des Use Cases erfolgt über das GUI. Klasse CApDataExportHandler Diese Klasse realisiert die Funktionalität der Haupt Use Case 1400 „Daten ausgeben“. Eine in ERA-TooL eingelesene und evtl. editierte Konfiguration soll in ASCII-Parameterfiles geschrieben wer-den. Der Benutzer hat die Möglichkeit, den Speicherort und die zu erstellenden Parameterfiles aus-zuwählen. Die zu schreibende Konfiguration wird nicht auf dessen Gültigkeit überprüft, da ERA-TooL beim Einlesen und Editieren keine ungültigen Werte akzeptiert. Somit ist die dargestellte Konfiguration immer gültig. Klasse CApDataImportHandler Diese Klasse realisiert die Funktionalität der Haupt Use Case 1300 „Daten einlesen“. Parameter- und/oder ein Beschreibungsfile sollen in ERATooL eingelesen werden können. Der Benutzer kann bestimmen, welche und von welchem Speicherort Files eingelesen werden sollen. Das Einlesen der Files durchwandert mehrere Gültigkeitsprüfungen: Einerseits werden die einzel-nen Files auf deren File-Aufbau überprüft und andererseits müssen die File-Versionen der eingele-senen Files übereinstimmen. Ist irgendeine Regel verletzt, wird der Einlesevorgang abgebrochen und kein File wird eingelesen. Es geht also nach dem Prinzip „Entweder alles oder nichts einlesen“. Klasse CApShowTableViewHandler Diese Klasse realisiert die Funktionalität des Use Case 1110 „Konfig in Tabelle darstellen“. Dies soll dem Benutzer die Möglichkeit bieten, die eingelesenen Parameter in einer Tabelle, ähnlich dem Excel, darzustellen und zu editieren. Diese Darstellung kann vom Benutzer nur über die Selektion der Parameterfiles im FileBrowser vorgenommen werden. Der File-Browser ist als Tab-Control und die Parameterfiles als TreeView dargestellt. Die Daten werden in einer DataGridView angezeigt. Als Datenquelle kann direkt die Datentabelle der jeweiligen Parametergruppe angegeben werden. Die Editierung der Tabelle kann wie im Excel vorgenommen werden. Es kann jedoch nur die Ko-lonne mit den Parameterwerten editiert werden, da die anderen Angaben nicht manipuliert werden sollten. Klasse CApParameterDetailViewHandler Diese Klasse realisiert die Funktionalität des Use Case 1120 „Konfig in Baumstruktur darstellen“. Die eingelesene Konfiguration wird im Group-Browser als XML-Baumstruktur abgebildet. Alle akti-vierten Parametersets werden mit Schwarz, alle deaktivierten, Hellgrau dargestellt. Somit ist sofort ersichtlich, welche Elemente verfügbar sind und welche nicht. Durch klicken auf ein Parameter-Element (Blatt des Baumes), wird der selektierte Parameter mit allen verfügbaren Angaben angezeigt Detail Dialog. Die Angaben stammen alle aus dem Be-schreibungsfile, welche für jeden Parameter abgerufen werden kann. Auch hier kann nur der Parameterwert editiert werden. Je nach Parametergültigkeitsbereich, kann der Wert über eine numerische Eingabebox, einer DropDown-Liste oder gar nicht editiert werden (Parameter ist schreibgeschützt).


Klasse CApParameterEditHandler Diese Klasse realisiert die Funktionalität des Use Case 1220 „Parameter in Baumstruktur editieren“. Editiert ein Benutzer einen Parameter über die XML-Baumstruktur im Detail-Dialog, wird die Funk-tionalität dieser Klasse verwendet. Sobald ein neuer Wert eingeben (numerisches Eingabefeld) oder selektiert (DropDown-List) wird, wird der darunter stehende Zahlenwert der Auswahl ange-passt. Bei der Editierung der Konfiguration in der Tabelle, übernimmt das GUI die Gültigkeitsprüfung der editierten Werte. Bei der Tabellendarstellung werden reine Zahlenwerte und keine Beschreibungs-texte aus dem Beschreibungsfile angezeigt und müssen somit auch nicht nachgeführt werden. Klasse CApWindowController Der CApWindowController stellt die Schnittstelle von Zugriffen aus dem ApController-Namespace zum ApGUI-Namespace zur Verfügung. D. h. alle Zugriffe innerhalb des Controllers müssen zwangsläufig über den CApWindowController erfolgen. Einerseits wird der CApWindowController zum Teil als „Durchlauferhitzer“ für die Methoden-Aufrufe der Controller-Klassen eingesetzt. Auf der anderen Seite sind die Aufrufe zentralisiert und ermöglichen einen einfachen Austausch des GUI-Namespaces. Zudem enthält der CApWindowController eine Statusmaschine, welche das Hauptfenster in Ab-hängigkeit der ausgeführten Aktionen zur Aktualisierung auffordert. Zu diesem Zweck besitzt die Klasse eine Referenz auf das MainWindow. Klasse CApModelController Ähnlich dem CApWindowController übernimmt der CApModelController die Kapselung der Control-ler-Aufrufe gegenüber dem Framework und vor allem dem CFwDataRepository. Bis auf den Logger und die Definitionen werden alle Zugriffe auf das Framework über den CApModelController ausge-führt. Dies hat den Vorteil, dass bei Änderungen im Repository oder sonstigen Framework-Komponenten nur in der Model-Klasse allfällige Änderungen bezüglich des Frameworkzugriffs an-gepasst werden müssen. Die Klasse besitzt das Framework und das DataRepository als Attribute. Die beiden Objekte wer-den beim Startup der ERATooL Applikation erzeugt.

Design

Seite 54 / 124

4.2.2.2 Namespace „ApGUI“

Namespace Beschreibung Das Applikations-Namespace ApGUI ist zuständig für alle Aspekte der Darstellung. Die meisten Aktionen werden vom Benutzer über das GUI gestartet. Deshalb werden die Aktionen vom Haupt-fenster ausgelöst und an den MainController übergeben. Dieser gibt die Kontrolle weiter an seine SubController. Ich habe sehr grossen Wert darauf gelegt, möglichst wenig Logik im GUI zu platzieren. Das GUI ist relativ „dumm“ und reagiert nur auf den Anstoss des Controllers, um Daten anzuzeigen oder zu aktualisieren. Somit war es möglich, das MVC-Pattern21 sauber abzubilden und die Grenzen zwischen Controller und View zu gewährleisten. Dies war jedoch mit einem grösseren Programmieraufwand verbun-den. Nichts desto trotz hat sich die Trennung gelohnt.

21 Siehe [MVC]


Abbildung 24: ApGUI Klassendiagramm

Klassendiagramm


Klasse CApERATooLMain Die Klasse CApERTooLMain implementiert das Hauptfenster22 der ERATooL Applikation. Das Main-Window ist in zwei Bereiche (Panel) unterteilt. Panel1 (links) beinhaltet die Navigation mit dem TabWindow, wo die beiden TreeView Browserfenster eingefügt sind. Panel2 (rechts) nimmt die User Controls für die Tabellen- oder Parameter Detail-Darstellung auf.

Abbildun

Panel1

Der Start aller Haupt Use Cases groller weitergeleitet. Die nachfolg

Aktion (Benutzer) Selektion des File/Open-Menüs

m_o

Selektion des Open-Symbols

m_o

Selektion des File/Save-Menüs

m_s

Selektion des Save-Symbols

m_s

Selektion des Maintenan-ce/Logging-Menüs

m_l_Cl

Selektion einer Parameter-Group im File-Browser

m_fMou

Selektion einer Parameter-Group im File-Browser mit der Maus

m_fMou

22 Nachfolgend MainWindow benann

TabControl

TreeView

g 25: Aufbau des ERATooL MainWindow

Panel2

eht vom MainWindow aus und wird umgehend an den MainCont-ende Auflistung zeigt die Interaktion und deren Reaktion:

Angesprochene Methode Reaktion (System) penMenuItem_Click Ausführung des Use Case

1300 „Daten einlesen“ penToolStripButton_Click Ausführung des Use Case

1300 „Daten einlesen“ aveToolStripMenuItem_Click Ausführung des Use Case

1400 „Daten ausgeben“ aveToolStripButton_Click Ausführung des Use Case

1400 „Daten ausgeben“ oggingToolStripMenuItem ick

Selektion des gewünschten Ausgabekanals des Log-gings

ileBrowserTreeView_Node seClick

Ausführung des Use Case 1110 „Konfiguration in Ta-belle darstellen“

ileBrowserTreeView_Node seDoubleClick

Ausführung des Use Case 1110 „Konfiguration in Ta-belle darstellen“

t


Selektion einer Parameter-Group im Group-Browser mit der Maus

m_groupBrowserTreeView_ NodeMouseClick

Ausführung des Use Case 1120 „Konfiguration in Baumstruktur darstellen“

Selektion einer Parameter-Group im Group-Browser mit der Tastatur

m_groupBrowserTreeView_KeyUp Ausführung des Use Case 1120 „Konfiguration in Baumstruktur darstellen“

Benutzer selektiert ein Tab (File- oder Group-Browser Tab)

m_mainTabControl_Selected IndexChanged

Je nach selektiertem Tab wird der TreeView aktuali-siert dargestellt

Benutzer beendet Apppli-kation über das x-Symbol

m_exitToolStripMenuItem_Click ERATooL Applikation wird beendet

Selektion des About-Dialogs

m_aboutToolStripMenuItem_Click About Dialog wird darge-stellt

Bei Windows-Applikationen wird das MainWindow immer als Erstes erzeugt. Das MainWindow be-sitzt den CApMainController als Attribut. Im Konstruktor setzt es seine eigene Referenz im Win-dowController, welcher über ein Property zum Setzen des MainWindows verfügt. Im Gegensatz zu allen anderen Objekt-Instanzierungen, werden die Dialoge nur bei dessen Benö-tigung instanziert („lazy creation“). Wie oben bereits beschrieben ist, werden die beiden User-Controls CapParaDetailUserCtrl und CapTableListUserCtrl bei deren Erzeugung ins Panel2 einge-fügt. Die beiden UserControls besitzen eine Referenz auf das MainWindow, um Meldungen auf dem MainWindow zu platzieren. Des Weiteren stellt das MainWindow der Applikation Message Boxen zur Verfügung, um Meldun-gen als Info, Warning und Error als Dialog darzustellen.

Abbildung 26: Message Box für eine Benutzer Information

Abbildung 27: Message Box für eine Benutzer Warnung

Die beiden Abbildungen zeigen eine Benutzer Information und eine Benutzer Warnung.


Klasse CApAboutDialog Das About Window ist ein Dialog, welcher Informationen wie Versionierung und Erzeuger der Ap-plikation an:

Abbildung 28: About Dialog

Dieser Dialog wird nur bei Bedarf erzeugt („lazy creation“). Klasse CApLocationDialog Der Location Dialog wird in ERATooL mehrfach für die Auswahl des Quell- oder Ziel-Pfads verwen-det. Die Beschriftungen (Titel, Radio Button) für den Dialog werden dynamisch, d. h. beim Erzeu-gen mitgegeben. Zudem werden je nach Einsatz des Dialogs Radio Button(s) angezeigt oder weg-gelassen.

Abbildung 29: Location Dialog für das Einlesen der Parameterfiles


Abbildung 30: Location Dialog für das Ausgeben der Parameterfiles

Dieser Dialog wird nur bei Bedarf erzeugt („lazy creation“). Klasse CApSelectParaGroupExportDialog Dieser Dialog wird für die Auswahl der zu exportierenden Parameterfiles verwendet. Als Auswahl-elemente werden Checkboxen verwendet.

Abbildung 31: Parameterfile Export Auswahl Dialog

Dieser Dialog wird nur bei Bedarf erzeugt („lazy creation“).


Klasse CApTableListUserCtrl Die Anzeige der Konfiguration als Tabelle wird in ein User Control ausgelagert und im Panel2 dar-gestellt. Die Tabelle ist im eigentlichen Sinne kein eigener Dialog oder ein Fenster, sondern ein Teil des MainWindow. Für diese Darstellung ist ein User Control das geeignete graphische Element. Die Daten der Tabelle stammen aus der DataTable der ausgewählten Parametergruppe. Diese wurde beim Einlesen der Parameter abgefüllt. Eine DataTable kann in .NET mit einfachen Mitteln direkt an ein DataGridView angebunden werden. Dies wird dann wie folgt angezeigt:

Abbildung 32: Darstellung der Konfiguration als Tabelle in DataGridView

Die Werte in der Werte-Kolonne können innerhalb der Wertebereiche editiert werden.


Klasse CApParaDetailUserCtrl Die Anzeige der Parameter-Detailanzeige wird wie die Tabellen-Ansicht in ein User Control ausge-lagert und im Panel2 dargestellt. Die Detailanzeige ist ein Teil des MainWindow. Für diese Darstellung ist ein User Control das geeignete graphische Element. Die Daten der Detail-anzeigen stammen fast ausschliesslich aus dem Beschreibungsfile, welches für diese Darstellung zwingend vorgängig eingelesen werden muss. Zur Navigation kann auf der linken Seite der Group-Browser verwendet werden, welcher die einge-lesene Konfiguration als Xml-Baumstruktur darstellt. Nicht aktivierte Sets werden ausgegraut. So-mit ist sehr schnell ersichtlich, welche Komponenten aktiv sind und welche nicht.

Abbildung 33: Parameter Detail Darstellung

Die Anzahl und Auflistung der dargestellten Grafikelemente (Textboxen und Labels) hängt von den Eigenschaften (Abhängigkeit, Deklaration der Sets, Indexe und Typen) des darzustellenden Para-meters ab.


Je nachdem ob ein Parameter numerische Werte oder textlich definierte Werte annehmen kann, wird entweder ein numerisches Eingabefeld oder eine Drop-Down Liste eingefügt. Es gibt auch Parameter, welche schreibgeschützt sind und somit nicht editiert werden können. Bei diesen wer-den die Eingabefelder grau hinterlegt. Das User Control wird somit dynamisch für jeden Parameter aufgebaut.

Abbildung 34: Parameter Detail Dialog mit Drop-Down Auswahlliste

Abbildung 35: Parameter Detail Dialog mit numerischem Eingabefeld

Abbildung 36: Parameter Detail Dialog mit schreibgeschütztem Eingabefeld


4.2.2.3 Namespace „ApManagement“

Namespace Beschreibung Im ApManagement Namespace ist lediglich die Klasse Program mit der Main()-Methode vorhanden. Klassendiagramm

Abbildung 37: ApManagement Klassendiagramm

Klasse Program Die Main()-Methode ist der Ausgangspunkt zum Starten der ERATooL Applikation. Beim Aufstarten des Programms wird als erstes die Main()-Methode aufgerufen, welche ihrerseits das Hauptfenster erzeugt. Zudem wird im Konstruktor das Logging-Ausgabemedium gesetzt: entweder wird auf die Konsole (Debug-Mode) oder ins File (Release-Mode) geloggt. Die Main()-Methode wird in einem try-catch Konstrukt ausgeführt. Somit werden nicht behandelte Exception schlussendlich von der Main()-Methode behandelt und mit einer Message Box für den Benutzer sichtbar gemacht.


4.2.2.4 Namespace „ApDefinitions“

Namespace Beschreibung Das ApDefinitions Namespace beinhaltet Definitionen und Enumerationen, welche von der Applika-tion verwendet werden. Diese werden definiert und sind für alle Applikations-Komponenten zentral verfügbar. Klassendiagramm

Abbildung 38: ApDefinitions Klassendiagramm

Enumerationen Das File EApGeneralDefinitions beinhaltet mehrere Enumerationen, welche in der Applikation ver-wendet werden. Das sind zum einen Definitionen für die Ausgabe des Loggings und zum anderen Definitionen für auftretende Events und deren darauf folgende Aktionen. Klasse CApVersion CApVersion ist eine statische Klasse, welche lediglich die Information der Haupt- und Applikations-Software-Version beinhaltet. Die beiden Software-Version können mit statischen Methoden als Zei-chenkette (String) ausgelesen werden. Die Software-Version wird im About Dialog dargestellt.


4.2.3 Services-Framework Namespaces

4.2.3.1 Allgemeines

Das Services Framework soll der Applikation Basis-Dienste, wie das Öffnen eines Files oder ein Logging, zur Verfügung gestellt werden. Die Klassen sind ihrer Funktionalität entsprechend auf Namespaces verteilt. Nachfolgend werden die Services-Framework Namespaces graphisch und textlich erläutert.

4.2.3.2 Namespace „FwLogger“

Namespace Beschreibung Das Logging soll während der Entwicklung und im Betrieb dazu dienen, ein Fehlverhalten der ERA-TooL Applikation aufzuzeichnen und somit den Fehler einfach und schnell zu beheben. Um diese Aufgabe zu erfüllen, habe ich mich schon in der Design Phase für das Apache Logging Framework log4net entschieden. Dieses erfüllt alle Forderungen und ist sehr einfach einsetzbar. Klassendiagramm

Abbildung 39: FwLogger Klassendiagramm

Klasse CFwLogger Der Logger ist als statische Klasse definiert und kann über das öffentliche Klassenattribut Logger von allen Komponenten benutzt werden. log4net wird als Bibliothek eingebunden (log4net.dll). Über diese Bibliothek können die folgenden 4 Logging-Stufen verwendet werden:

• Log-Info: Loggen von Informationen • Log-Warning: Loggen von Warnungen • Log-Error: Loggen von Errors • Log-Fatal: Loggen von fatalen Errors

Die Logging-Einstellungen werden über ein Xml-Konfigurationsfile vorgenommen, welche vor der Benutzung des Loggers eingelesen werden muss. Die Konfiguration des Loggings wird im Imple-mentations-Kapitel behandelt.


log4net unterstützt die Ausgabe des Loggings auf diverse Devices, wie Logging in ein File, auf die Konsole, in eine Datenbank, über SMTP als Email usw. ERATooL unterstützt das Logging auf die Konsole (Default Einstellung im Debug-Mode) und in ein File (Default Einstellung im Release-Mode). Zudem kann das Logging deaktiviert werden. Die Wahl des Ausgabe-Devices kann im Betrieb eingestellt werden. Die Einstellungen werden jedoch nicht persistent gespeichert und somit wird beim nächsten Start von ERATooL wieder auf das Default-Device geloggt.

4.2.3.3 Namespace „FwDefinitions“

Namespace Beschreibung Der Namespace beinhaltet Definitionen, welche vom Framework und auch von der Applikation ver-wendet werden. Klassendiagramm

Abbildung 40: FwDefinitions Klassendiagramm


Exception Klassen Alle selber definierten Exception Klassen werden von der ApplicationException Klasse abgeleitet. Unstimmigkeiten des Header oder Body der Parameter- oder Beschreibungsfiles führen zu einer Header- bzw BodyException. Diese werden beim Einlesen der Files geworfen und von den aufru-fenden Funktionen ausgewertet und weiter verarbeitet. Klasse CFwVersion CFwVersion ist eine statische Klasse, welche lediglich die Information der Framework-Softwareversion beinhaltet. Die Software-Version kann mit einer statischen Methode als Zeichen-kette (String) ausgelesen werden. Die Softwareversion wird im About Dialog dargestellt. Klasse CFwGeneralDefinitions Diese statische Klasse beinhaltet Definitionen für das Framework, welche aber auch von der Appli-kation benötigt werden. Somit sind alle Attribute mit dem public Modifizierer deklariert. Klasse CFwDataType Die DataType Klasse ist eine reine Daten Klasse, welche ausschliesslich aus privaten Attributen und öffentlichen Property-Methoden (Setter und Getter Methoden) besteht. Die Klasse beinhaltet alle Eigenschaften als Attribute, welche ein einzelner Parameter annehmen kann. Der Datentransfer einzelner Parameter wird mit dieser Daten Klasse realisiert.


4.2.3.4 Namespace „FwFileProcessing“

Namespace Beschreibung Grundsätzlich beinhaltet der FileProcessing Namespace statische Klassen, um Daten aus Files zu lesen und Daten in Files zu schreiben. Einerseits werden ASCII-Parameterfiles und andererseits XML-Files verarbeitet. Klassendiagramm

Abbildung 41: FwFileProcessor Klassendiagramm

Klasse CFwCsvReader In einem ersten Schritt werden die einzulesenden Parameterfiles von der Roboter Steuerung er-zeugt. Diese sind die Ausgangsdaten für den nachfolgenden Einlesevorgang. Die statische Klasse liest ASCII-Parameterfiles ein, welche im CSV-Format23 aufgebaut sind. Die Parameterfiles werden auf die Gültigkeit des Headers und des Bodys überprüft und bei Korrektheit eingelesen. Ist der Header oder Body fehlerhaft, wird der Einlesevorgang abgebrochen und bereits gelesene Daten gelöscht.

23 Siehe [CSV-Format]


Beim Parsen des Headers werden die Header Daten nur verifiziert. Beim Parsen des Bodys werden die eingelesenen Daten in eine Datenstruktur abgelegt. Als Datenablage wird die Klasse DataTable verwendet, welche ein spezieller Datentyp des .NET Frameworks ist. Die DataTable entspricht ei-ner einzelnen Datenbank-Tabelle. Wie in einer „waschechten“ Datenbank, können die abgelegten Daten einfach weiter verarbeitet werden (suchen, sortieren, löschen). Aus diesen Gesichtspunkten ist die DataTable die optimale Datenstruktur, um möglichst einfach und schnell auf die eingelesenen Daten zu zugreifen. Klasse CFwCsvWriter Der Writer macht das gleiche wie der Reader, nur in umgekehrter Form. Aus den eingelesenen Daten einer DataTable werden Parameterfiles im CSV-Format24 erzeugt. Die Daten werden vor dem Schreiben ins File nicht mehr verifiziert, da das Einlesen wie das Editieren keine fehlerhaften Daten zulassen. Die so erzeugten Daten werden in einem zweiten Schritt in die Roboter Steuerung eingelesen und somit wird das Roboter System neu konfiguriert. Klasse CFwXmlReader Die statische Klasse liest das Beschreibungsfile (basierend auf XML) ein und prüft das Dokument auf dessen Gültigkeit des Headers und des Bodys. Das XML-Parameter Beschreibungsfile wird mit einem DOM25-Reader ins RAM gelesen. Die Klasse bietet auch Schnittstellen, um im XML -File zu navigieren und Werte auszulesen. Die Navigation im XML-File wird mit XPath26 realisiert.

24 Siehe [CSV-Format] 25 Siehe Document Object Model [DOM] 26 Siehe [XPath]


4.2.3.5 Namespace „FwDataRepository“

Namespace Beschreibung Ein zentraler Aspekt von ERATooL sind die Daten und dessen Organisation und Verarbeitung. Eine Konfiguration kann bis zu 15000 Parameter beinhalten. Die einzulesenden Daten stammen aus den Parameterfiles und/oder aus dem Beschreibungsfile. Die Parameter müssen in einer geeigneten Datenstruktur abgelegt werden. Jeder Parameter kann eindeutig über dessen Adressierung wie Parameternummer, Setnummer, Typnummer und Index-nummer angesprochen werden. Je nach Parametergruppe werden jedoch nicht alle Adressierungs-elemente verwendet. Klassendiagramm

Abbildung 42: FwDataRepository Klassendiagramm


Kasse CFwDataRepository Das CFwDataRepository ist der Datenbehälter der ERATooL Applikation. Das Repository beinhaltet 10 Parametergruppen, welche ihre Daten je in einer DataTable abgelegt haben. Die Daten aller 10 Parametergruppen werden wiederum in einem Dictionary abgelegt. Ein Dictionary ist eine Datenstruktur, welche Daten und dazugehörige Schlüssel ablegen kann. Als Daten gelten die Datenklassen der Parametegruppen (CFwParameterGroup) und als Schlüssel wird der dazugehörige Namen der Parametergruppe als Zeichenkette dazu abgelegt. Mit dem Schlüssel können die abgelegten Daten sehr einfach aus dem Dictionary herausgeholt werden. Im Weiteren übernimmt das DataRepository alle Aufgaben, welche Parametergruppen übergrei-fend ausgeführt werden. Das DataRepository ist auch der Einstiegspunkt zu jeder Parametergrup-pe und kapselt diese. D. h. jeder Zugriff auf die Parametergruppe erfolgt immer über das DataRe-pository. Klasse CFwParameterGroup Die Daten jedes Parameterfiles werden als Parametergruppe in eine Instanz der Klasse CFwPara-meterGroup abgelegt. Somit sind alle Parametergruppen separiert als Objekt gespeichert. Die Header Daten werden als Attribute und die Body Daten werden in einer Da aTablet

t Datenstruk-

tur abgelegt. Die Da aTable hat ähnliche Eigenschaften wie eine Datenbank, welche jedoch auch als einzelne Tabelle verwendet werden kann. Es ist möglich die Tabelle zu sortieren, zu filtern und deren Werte zu manipulieren. Zudem kann eine DataTable einfach an ein DataGridView zum Anzeigen der Daten in tabellarischer Form ver-wendet werden.


4.3 Instanzierung der Objekte während der Startup-Phase Nachfolgende Ausführungen sollen den Aufstartvorgang der ERATooL Applikation bezüglich der Interaktionen und den zu erzeugenden Objekte beleuchten. Beachte: Die Bezeichnungen werden mit anonymisierten Objekten (Klasseninstanzen) deklariert.

Abbildung 43: Sequenzdiagramm während Startup-Phase

Die Objektinstanzierung erfolgt nach folgendem Ablauf:

• die Main-Methode erzeugt ein Objekt der Klasse CApERATooLMain, was dem Hauptfenster entspricht

• der MainController erzeugt seine SubController wie Window- , Model- und HandleController • der ModelController erzeugt das Repository • der HandleController erzeugt seine Use Case Handler


Alle anderen Objekte werden erst bei Bedarf zur Laufzeit erzeugt („lazy creation“). Dies sind vor allem Objekte der GUI-Dialoge, welche nicht „auf Vorrat“ erzeugt werden. Nachfolgendes Objektdiagramm zeigt graphisch, welche Objekte nach Ausführung der Startup-Phase instanziert sind und wer welche Objekte erzeugt. Beachte: Die Bezeichnungen werden mit anonymisierten Objekten (Klasseninstanzen) deklariert.

Abbildung 44: Objektdiagramm nach Startup-Phase


4.4 Ablaufbetrachtungen nach Benutzer-Interaktionen Nachfolgende Betrachtungen gelten den Abläufen und Aktivitäten nach der Betätigung von Benut-zer-Interaktionen.

4.4.1 Auswahl der Speicherablage des Beschreibungsfile beim Einlesen

Nachfolgendes Sequenzdiagramm zeigt die Abläufe, nach dem Starten des Use Case 1300 „Daten einlesen“, nachdem der Benutzer das Menü File/Open gewählt hat.

Abbildung 45: Sequenzdiagramm bei der Selektion des Speicherorts beim Einlesen

Alle Use Case Abarbeitungen werden immer durch Benutzer-Interaktionen (Maus- oder Tastatur-Klicks) gestartet. In diesem Fall selektiert der Benutzer das File/Open Menü. Das Hauptmenü gibt unmittelbar nach der Aktion die Kontrolle an den MainController ab. Dieser delegiert die weiteren Schritte dem HandleController, welcher seinerseits die Kontrolle an den DatenImportHandler weiter gibt. Dieser Handler ist zuständig für die Abarbeitung des Use Case „Daten einlesen“. Der Handler muss nun einen Dialog für die Selektion des Speicherorts wählen. Da er keine GUI-Elemente erzeugen kann, delegiert er dies weiter an den WindowController. Dieser ist die Schnitt-stelle zum GUI.

Design

Seite 75 / 124

Der WindowController leitet die Anfrage an das Hauptfenster weiter, welches nun den Dialog zur Laufzeit instanziert. Dies wird in der Fachsprache als „lazy creation“ bezeichnet, da man nur bei Bedarf („faul“) Objekte instanziert. Danach werden die gewählten Eingaben des Benutzers ausgelesen. Nachdem der Benutzer den Dialog beendet hat, wird auch der Dialog mit der Methode Dispose() zerstört. Somit erreicht man ein effektives Speichermanagement, da man die Zerstörung selber anstossen kann. Anhand der ausgelesenen Daten entscheidet nun der DataImportHandler über die weiteren Schritte. Wie aus diesen Ausführungen zu entnehmen ist, lege ich viel Wert auf klare Trennung zwischen der Logik im Controller und der Darstellung im GUI. Es ist auch ersichtlich, dass diese Trennung einen grösseren Codierungsaufwand mit sich bringt, aber die Schnittstellen sind sehr sauber und einfach zu verstehen. Da ich eine Single-Task Anwendung realisiere, gibt es keine Entkopplung nach dem Start der Use Case Abarbeitung. D. h. der Calling-Stack beinhaltet einige Methodenaufrufe, was jedoch zu keinen Problemen führt.


Abbildung 46: Sequenzdiagramm für die Auswahl der zu schreibenden Parameterfiles

4.4.2 Auswahl der zu schreibenden Parameterfiles


r t

Der Ablauf im Sequenzdiagramm in Abbildung 46 ist sehr ähnlich wie in Abbildung 45. Nachdem der Benutzer eine Interaktion zum Starten eines Ablaufs (Use Case) ausgelöst hat, läuft die Zuwei-sung und Abarbeitung grundsätzlich immer gleich ab:

• Das MainWindow reagiert auf Benutzer-Interaktionen (Events) • Das MainWindow gibt die Kontrolle sofort an den MainController ab • Der MainController delegiert die Ausführung an den HandleController ab • Der HandleController setzt den aktiven Use Case Handler und startet die Abarbeitung des

Use Case mit dem Aufruf der Methode perfo mAc ion() • Die Abarbeitung des Use Case liegt in der vollen Verantwortung des entsprechenden Hand-

lers, welcher den Ablauf des Use Case in kleine Schritte unterteilt und diese in einer Sta-tusmaschine durchläuft

• Muss der Handler auf den Repository- oder FileProcessing Namespace im Framework zugreifen, erfolgt dies immer über den ModelController

• Muss der Handler auf das GUI zugreifen, kann er dies nur über den WindowController durchführen

• Am Ende der Ausführung wird das Fenster nach Bedarf aktualisiert oder gar neu aufgebaut

Implementation Seite 78 / 124

5 Implementation

5.1 Implementation der Design Pattern

5.1.1 Singleton Pattern

Es gibt diverse Arten, wie man das Singleton Pattern mit C# implementieren kann. Ich habe mich für die nachfolgende Implementation entschieden. public sealed class Singleton { static readonly Singleton instance=new Singleton(); // Explicit static constructor to tell C# compiler // not to mark type as beforefieldinit static Singleton() { } Singleton() { } public static Singleton Instance { get { return instance; } } }

Abbildung 47: Codeschnipsel der Singleton Implementation in C#

Der Codeschnipsel der Singleton Implementation ist Thread-Save, was jedoch bei der Single-Thread Realisierung von ERATooL nicht benötigt würde. Die Erzeugung des Singleton Objekt wird beim erstmaligen Aufruf der Klasse realisiert. Das erzeugte Objekt wird einer Klassenvariablen zu-gewiesen, welche nur einmal pro Klasse instanziert werden kann.

5.1.2 Observer Pattern mit Events

Sobald Daten im Repository verändert werden, soll dies der Visualisierung mitgeteilt werden, damit sich diese aktualisieren kann. Die Visualisierung beobachtet die Daten. Das Observer Pattern sorgt lediglich dafür, dass die Änderung bis zur Visualisierung vorstösst. Zudem soll das Model nicht er-fahren, wer ihn beobachtet. Dieser Benachrichtigungsmechanismus kann mit der Programmier-sprache C# mit Events realisiert werden. Ein Objekt (Observer), welches ein anderes Objekt (Observable) beobachtet und bei einer Ände-rung der Daten benachrichtigt werden will, muss beim Beobachteten eine Methode installieren. Die Installation der Methode wird auf ein so genanntes Event-Attribut vorgenommen. Das beobachtete Objekt weiss jedoch nicht, wer sich an ihm installiert hat. Ein Event ist ein Platzhalter für Code, der ausgeführt wird, wenn das Event ausgelöst bzw. aktiviert wird. Events werden durch eine Aktion des Benutzers, durch Programmcode oder vom System ausgelöst. Tritt nun eine Datenänderung ein, führt das beobachtete Objekt den Event aus, was einem impliziten Aufruf der installierten Methode gleich kommt.


Abbildung 48: Aufbau und Struktur des Event Handling

Abbildung 48 zeigt auf, wie das Event Handling in ERATooL aufgebaut ist. Zum einen werden Me-thodenaufrufe (ausgezogene Pfeile) von der hierarchisch oberen Struktur auf die untere vorge-nommen (von Applikation zum Framework). Zum anderen werden die Event-Aufrufe (gestrichelte Pfeile) entkoppelt von der hierarchisch unteren Struktur auf die Obere vorgenommen (von Frame-work auf Applikation). Somit ist die Schichtenarchitektur nicht verletzt und die Entkopplung durch Events gegeben. Aus der oberen Abbildung ist ersichtlich, dass jegliche Datenänderungen der Parametergruppen vom DataRepository erfasst werden. Der ModelController muss also lediglich das DataRepository beobachten, um alle Datenänderungen zu erfassen. Danach sendet der ModelController die Ände-rung über einen Methodenaufruf zum WindowController, welcher seinerseits über einen Metho-denaufruf auf das MainWindow zugreift. Das MainWindow ruft seinen EventHandler auf, welcher schlussendlich das UserControl über die Datenänderung informiert. Somit kann sich das UserControl gemäss den Datenänderungen aktuali-sieren.


Abbildung 49: Sequenzdiagramm: Installation der EventHandler

Abbildung 49 zeigt wer sich an welchem EventHandler installiert. Die Installation der EventHandler wird mit 3 Aktionen ausgeführt:

• Während der Startup Phase • Beim Einlesen einer Parametergruppe • Beim Selektieren eines Parameters im Detail-Dialog


Abbildung 50: Sequenzdiagramm: Benachrichtigung der Datenänderung

Aus Abbildung 50 ist ersichtlich, wie die Aufrufabfolge bei einer Datenänderung der Tabelle erfolgt. Der Auslöser ist die DataTable, welche Alles ins Rollen bringt. Durch die konsequenten Schnittstel-len zwischen den einzelnen Namespaces und Schichten, ergibt sich ein grosser Aufruf-Stack. Viele Methodenaufrufe leiten den Aufruf lediglich an die nächste Instanz weiter, um die Aufrufhierarchie nicht zu verletzen. Dieser Mehraufwand ist sicherlich ein Nachteil. Es gilt jedoch zu beachten, dass diese Events nur im Detail Dialog generiert werden und die geän-derten Daten als Information mitgegeben werden. Schlussendlich erhält das UserControl die Da-tenänderung und kann sich somit updaten.

5.2 CFwCsvReader und CFwCsvWriter Aufgrund meiner Erfahrung war mir bewusst, dass das Schreiben eines fehlerfreien CSV-Parsers und CSV-Writers relativ zeitaufwändig ist. Zudem war ich mir fast sicher, dass die Implementation als Open Source Code im Internet verfügbar sein sollte. Basierend auf diesen Überlegungen habe ich einige Recherchen im Internet angestellt. Schon nach kurzer Zeit (15 Minuten) bin ich auf eine brauchbare Implementation gestossen. Die vorgefundene Implementation der beiden Klassen CsvWriter27 und CsvParser28 war exakt auf meine Bedürfnisse abgeschnitten:

• Klasse CsvWriter: Erzeugen eines Files im CSV-Format basierend auf Daten einer DataTable Datenstruktur

• Klasse CsvParser: Einlesen eines Files im CSV-Format in eine DataTable Datenstruktur Grundsätzlich mussten nur noch folgende Änderungen vorgenommen werden:

• Als Trennzeichen sollen nebst Leerschlägen auch Tabulatoren gelten • Einlesen bzw. ausgeben der beiden Header-Zeilen • Exception Handling falls File Struktur (Header oder Body) nicht korrekt ist • Separates Lesen und Schreiben des Headers und des Bodys • Die beiden Klassen werden statisch definiert, da dieser Dienst zentral und nur einmalig zur

Verfügung gestellt werden soll Die ursprüngliche Bezeichnung der Klasse CsvParser habe ich für die Integration in ERATooL auf CsvReader umbenannt. Mit diesen minimalen Änderungen konnte ich die Implementation in ERA-TooL integrieren und die Dienste der beiden Klassen nutzen. Gemäss Angaben des Autors, kann der Code der beiden Klassen CsvWriter und CsvParser ohne Einschränkungen in jeder Applikation eingebunden werden (siehe Referenz im Literatur und Medienverzeichnis).

27 Siehe [CsvWriter] 28 Siehe [CsvParser]


5.3 Interaktion zwischen Controller und GUI Beim Design des Systems habe ich darauf geachtet, dass die Interaktion zwischen dem Controller und dem GUI möglichst sauber abläuft. D. h. die Kommunikation zwischen dem Controller und dem GUI sollten nur über definierte Schnittstellen stattfinden. Der Controller sollte nicht direkt auf GUI-Elemente zugreifen können. Somit ist es relativ einfach möglich, eine neue Implementation des GUI (Visualisierung), ohne grosse Änderungen im Control-ler (Logik) vorzunehmen. Der strikte Zugriff über definierte Schnittstellen hat sich jedoch in einen grösseren Aufwand nie-dergeschlagen. Trotzdem hat es sich gelohnt, dies sauber zu trennen und den Mehraufwand in Kauf zunehmen.

5.4 Arbeiten mit .NET Datenstrukturen

5.4.1 Verwendung eines Dictionary als Datenstruktur

Folgende Zeile demonstriert das Anlegen des Repository als Dictionary: Dictionary<string, CFwParameterGroup> m_dataRepository; Einfügen einer Parametergruppe in das Repository: string groupName = „chuck“; CFwParameterGroup paraGroup = new CFwParameterGroup(); m_dataRepository.Add(groupName, paraGroup); Auslesen einer Parametergruppe vom Repository: string groupName = „chuck“; CFwParameterGroup paraGroup; m_dataRepository.TryGetValue(groupName, out paraGroup);

Abbildung 51: Verwendung eines Dictionary als Datenstruktur

DatenSchlüssel

Schlüssel Daten

DatenSchlüssel


5.4.2 Arbeiten mit einer DataTable

Folgende Zeile demonstriert das Suchen eines bestimmten Datensatz: Definition des Selection-Statement: String statement = "PARA ='P101' and SET = '001' and INDEX = '006'" Durchführung der Abfrage durch den Select-Befehl DataRow[] foundRows = m_dataTable.Select(statement); Auslesen des VALUE-Werts der gefundenen Datenreihe foundRows[0]["VALUE"] = parameterData.Value;

Abbildung 52: Arbeiten mit der Datenstruktur DataTable in .NET

5.5 Arbeiten mit XML unter .NET 2.0 Das .NET Framework bietet viele Möglichkeiten um XML-Files einzulesen, auszugeben oder zu be-arbeiten. Als XML Framework werden die Klassen im .NET Framework bezeichnet, die direkt mit der Verwendung von XML zu tun haben. Grundlage dafür bilden die Klassen im Namespace Sys-tem.Xml. Es werden folgende Standards unterstützt:

• XML 1.0 und XML Namespaces • XML Schema • XPath 1.0 • XSL und XSLT • DOM Level 2 Core

5.5.1 Einlesen des XML-Beschreibungsfile mit DOM29

-

Beim Darstellen der Parameter Baumstruktur wie auch beim Parameter Detail-Dialog sollen nur die benötigten Elemente aus dem Beschreibungsfile gelesen werden. Dies kann mit dem XmlDocument-Objekt realisiert werden. Ein solches Objekt erlaubt über verschiedene Methoden den wahl-freien lesenden und schreibenden Zugriff auf ein XML-Dokument. Die XmlDocument-Klasse implementiert das DOM (Document Object Model). Das DOM legt einen Satz an Klassen und deren Methoden und Eigenschaften fest, die ein XML-Dokument im Arbeits-speicher repräsentieren.

5.5.2 Traversieren im XML-Beschreibungsfile mit XPath30

DOM stellt Methoden zur Verfügung, welche mit Hilfe der Adressierungssprache XPath gezielt auf einzelne Elemente in einem XML-Dokument zugreifen können. XPath ist sehr mächtig und erlaubt eine sehr flexible Adressierung in einem XML-Dokument.

29 Siehe [DOM] 30 Siehe [Xpath]


5.6 Logging mit log4net

5.6.1 Allgemeines

log4net ist ein Framework zum Loggen von Anwendungsmeldungen unter .NET. Es wird von un-zähligen Open Source als auch von kommerziellen Softwareprodukten verwendet. log4net ist ein Teil des Logging-Projekts der Apache Software Foundation und steht unter der Apache-Lizenz31. Neben den .NET-Sprachen unterstützt das Framework unter anderem folgende Programmierspra-chen bzw. Plattformen:

• Log4j Logging für die Programmiersprache Java • Log4cpp Logging für die Programmiersprache C++ • Log4perl Logging für die Programmiersprache Perl • Log4php Logging für die Programmiersprache PHP

Mittels Appender (Ausgabe-Device) kann je nach Wunsch auf verschiedene Ausgabe Kanäle bzw. in alle gleichzeitig geloggt werden:

• ConsoleAppender Gibt auf Standardausgabe aus

• FileAppender Schreibt in eine Datei

• RollingFileAppender Beginnt eine neue Datei ab einer gewissen Größe

• DailyRollingFileAppender Beginnt zu gewissen Zeiten mit einer neue Datei

• NTEventLogAppender Schreibt ins Ereignisprotokoll des Windows-Systems

• SMTPAppender Schickt bei gewissen Meldungen eine Mail

Es gibt auch noch weitere Appender.

5.6.2 Konfiguration von log4net

5.6.2.1 Einbinden der Bibliothek

Benötigte Schritte 1.) Herunterladen der Assembly mit der Version 1.2.10 von der Apache Download Webseite File incubating-log4net-1.2.10.zip. 2.) Entpacken des *.zip-Files 3.) Entpacktes Assembly log4Ne dllt.

im Ordner log4net-1.2.10/bin/net/2.0/release im Applikati-onsordner (ERATooL\ApERATooL\bin\Debug) ablegen. 4.) Die Applikation und das Framework müssen das Assembly als Referenz einbinden. Mit der De-klaration „using log4net“ kann das Assembly nun angesprochen werden.

31 Siehe [log4net Apache Lizenz]


5.6.2.2 Konfigurationsfile

Um das Logging Verhalten (welche Stufen werden geloggt, wohin wird geloggt …) zu konfigurie-ren, muss ein Logger Konfigurationsfile mit der Endung *.config definiert werden. Das Konfigurati-onsfile ist ein XML-File, in welchem das Logging-Verhalten mit XML-Tags vorgenommen werden kann. Konfiguration, um auf die Konsole zu loggen 1: <configuration> 2: <configSections> 3: <section name="log4net" 4: type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" /> 5: </configSections> 6: <log4net threshold=”DEBUG”> 7: <appender name="Console" type="log4net.Appender.ConsoleAppender"> 8: <layout type="log4net.Layout.PatternLayout"> 9: <conversionPattern value="%d %-5p %5rms %m%n"/> 10: </layout> 11: </appender> 12: <root> 13: <level value="ALL"/> 14: <appender-ref ref="Console"/> 15: </root> 16: </log4net> 17: </configuration>

Abbildung 53: Konfiguration für Logging auf die Konsole

In Zeile 7 wird der „appender“ Console eingetragen und in Zeile 14 darauf verwiesen. Dieser Ein-trag definiert das Loggen auf die Konsole. Mit dem Wert „ALL“ für den level in Zeile 13, werden alle Informationen ungefiltert geloggt. Das „conversion pattern“ definiert (Zeile 9) das Ausgabeformat des Logging Eintrags. Nachfolgend ist ein Beispiel eines Logging Eintrags aufgeführt: 2008-06-11 14:11:09,546 DEBUG 562ms This is a debug message Konfiguration, um in ein File zu loggen 1: <configuration> 2: <configSections> 3: <section name="log4net" 4: type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" /> 5: </configSections> 6: <log4net threshold=”DEBUG”> 7: <appender name="RollingLogFileAppender" 8: type="log4net.Appender.RollingFileAppender"> 9: <file value="C:\\Temp\\ERATooL_Logging\\ERATooL_Log.log" /> 10: <appendToFile value="true" /> 11: <rollingStyle value="Size" /> 12: <maxSizeRollBackups value="10" /> 13: <maximumFileSize value="1MB" /> 14: <staticLogFileName value="true" /> 15: <layout type="log4net.Layout.PatternLayout"> 16:  18: <conversionPattern value="%d %-5p %5rms %m%n" /> 19: </layout> 20: </appender> 21: <root> 22: <level value="ALL" /> 23: <appender-ref ref="RollingLogFileAppender" /> 24: </root> 25: </log4net> 26: </configuration>

Abbildung 54: Konfiguration für Logging in ein File

In Zeile 7 wird der „appender“ RollingFileAppender eingetragen und in Zeile 15 darauf verwiesen. Dieser Eintrag definiert das Loggen in ein File mit folgenden Einstellungen:

• Zeile 9: Definition des Pfads und des File Namen des Logging Files • Zeile 10: Neue Logging Einträge werden im bestehenden Logging File angehängt • Zeile 11: Kriterium für die Erzeugung eines neuen Files ist die File Grösse • Zeile 12: Anzahl der Total zu erzeugenden Logging Files (File Ringbuffer) • Zeile 13: File Grösse nach der ein neues File erzeugt wird

Das „conversion pat ernt “ definiert das Ausgabeformat des Logging Eintrags. Nachfolgend ist ein Beispiel eines Logging Eintrags aufgeführt: 2008-06-11 14:11:09,546 DEBUG 562ms This is a debug message

Abbildung 55: Anlegen der Rollup Backup Logging Files

Die oben abgebildete Darstellung zeigt, wie die Logging Files beim Erreichen der definierten Fi-legrösse abgelegt und bis zu 10 Backup Logging Files erzeugt werden. Konfiguration, um das Logging zu deaktivieren 1: <configuration> 2: <configSections> 3: <section name="log4net" 4: type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" /> 5: </configSections> 6: <log4net threshold="OFF"/> 7: </configuration>

Abbildung 56: Konfiguration für die Deaktivierung des Loggings

In Zeile 6 deaktiviert das Attribut threshold mit dem Wert “OFF“ das Logging.


5.7 Code Dokumentation mit NDoc2005

5.7.1 Allgemeines

Für die Dokumentation des Codes habe ich den .NET CodeGenerator NDoc2005 eingesetzt. NDoc2005 kann Dokumentationen aus .NET Assemblies (*.exe Files) und Klassenbibliotheken (*.dll) generieren. Das Tool bedient sich einiger Dokument-Generatoren, um die folgenden Forma-te zu erzeugen:

• MSDN-style HTML Help Format Ausgabe als *.chm • Visual Studio .NET Help Format Ausgabe als HTML Help 2 • MSD-Online Style Ausgabe als Web-Pages

NDoc2005 basiert auf NDoc und wurde für die Verwendung mit Visual Studio 2005 und dem .NET Framework V2.0 entwickelt. Da dies ein Open Source Projekt von SourceForge32 ist, sind die Sour-cen als GPL General Public Licence erhältlich. Beachte: Die aktuellste NDoc Version 1.3.1 kann nur für .NET Framework 1.0 und 1.1 eingesetzt werden. Um NDoc mit .NET 2.0 und dem Visual Studio 2005 einzusetzen, muss NDoc2005 verwendet wer-den!!!

5.7.2 NDoc2005 einrichten

Das Einrichten von NDoc2005 verlangt ein paar spezielle Eingriffe, da die zur Verfügung gestellt Applikation auf der SourceForge Web-Page nicht funktioniert. Man muss die Sourcen herunterladen und diese neu kompilieren. Zudem müssen noch einige Änderungen im Code vorgenommen wer-den, damit das Tool einwandfrei funktioniert33.

5.7.3 XML-Dokumentationstags

Die nachfolgenden XML-Beschreibungstags werden in der Code-Dokumentation verwendet:

• param Das param Tag sollte für die Beschreibung eines Parameters in einer Methodendeklaration verwendet werden.

• returns Das return Tag sollte für die Beschreibung eines Methoden-Rückgabewerts verwendet wer-den.

• summary Das summary Tag wird für alle generellen Beschreibungen wie Variablen, Methoden und Konstanten verwendet.

32 Siehe [NDoc2005] 33 Siehe Web-Blog im Anhang „Anpassung der Sourcen von NDoc2005


5.7.4 Dokumentation mit NDoc2005 erzeugen

NDoc2005 benutzt als Eingangsdaten das Assembly-File (ApERATooL.exe) der Applikation und die Klassenbibliothek des Services Framework (FwERATooL.dll. Beide Files werden von der Entwick-lungsumgebung erzeugt. Beim Erzeugen der Dokumentation muss der Pfad für die Ausgabe und das Ausgabeformat ange-geben werden.

Abbildung 57: NDoc2005 GUI zum Erstellen der Code Dokumentation

Ausführbare Datei und Klassenbibliothek

Compile-Button

Eingabefenster für die Konfiguration der Dokumentation

Mit dem Compile-Button wird die Code-Generierung gestartet.


Abbildung 58: Code-Dokumentation in der HTML Web-Darstellung

Mit dem Aufruf der index.html Seite wird die Dokumentation im Web-Browser dargestellt.

Abbildung 59: Code-Dokumentation in der CHM-Helpfile

Durch den Aufruf des Files „ERATooL_Code_Documentation.chm“ wird die Dokumentation als CHM-Helpfile dargestellt.

Testing

Seite 90 / 124

6 Testing

6.1 Test Koordinaten

6.1.1 Zweck des Tests

• Nachweis der Funktionstauglichkeit der wichtigsten Anwendungsfälle. • Verhindern von schädigenden Aktionen des Programms, welche dem Roboter nach dem

Importieren der erzeugten Files zu einer Fehlkonfiguration und somit zu einem Schaden führen könnten Erzeugen von korrupten Parameterfiles und von Parameterfiles mit fal-schen Werten.

• Finden von Fehlern in Analyse, Design und Implementation.

6.1.2 Testablauf

Jede Testsequenz startet mit definierten Anfangsbedingungen. Jeder Testfall beginnt mit dem Starten von ERATooL und wird mit dem Schliessen von ERATooL beendet.

6.1.3 Test Objekt

Test der entwickelten ERATooL Anwendung bestehend aus Applikation und Services Framework. Die Tests werden nicht pro Schicht (Applikation oder Services Framework) sondern als Ganzes (ERATooL Anwendung) durchgeführt.

6.1.4 Test Einschränkungen

Um die Funktionalität einer Software zu garantieren, muss ein umfangreiches Testing durchgeführt werden. Einerseits müssen die Standard (Schönwetter Test-Cases) und andererseits die alternati-ven Abläufe getestet werden. Wegen der beschränkt zur Verfügung stehenden Zeit, werde ich mich bei der Testausführung fast ausschliesslich auf die Standard Abläufe beschränken.

6.1.5 Test Umgebung

6.1.5.1 Test Soft- und Hardware

• Laptop Intel Pentium M 2 GHz / 2GB Arbeitspeicher / 100 GB Harddisk • Windows XP Professional, SP2 • .NET Framework V2.0 Service Pack 1 • .NET Runtime Maschine

6.1.5.2 Test Daten

• Beschreibungsfile: ParameterDescription_V02_TestingFile_valid_ERM_V520.xml • Parameterfile: ChuckConfig_TestingFile_valid_ERM_V520.dat

6.1.5.3 Testbewertung für den Befund

Bezeichnung Aktion Fehler Test ist fehlerhaft. Fehler ist gravierend und muss zwingend behoben werden Mängel Test ist fehlerhaft. Beheben des Fehlers, falls Aufwand klein ist. Sonst OK.

OK Test erfolgreich

6.1.5.4 Nomenklatur

• TF steht für Testfall und jeder Testfall hat eine eindeutige Nummer • Die Nummern der Testfälle sind so gewählt, dass sie die gleiche Zahl aufweisen, wie

die Nummer des dazugehörigen Use Case. Somit können die Test Cases einfach zu den Use Cases referenziert werden.

Testing Seite 91 / 124

6.2 Testsession

6.2.1 Testsequenz 0000: Allgemeine Tests

6.2.1.1 Vorbereitung

Keine

6.2.1.2 Testszenario 1: Applikation starten

Testfall Beschreibung Aktionen Soll Ist Befund TF_0001 Benutzer startet

ERATooL Applikation im Release Modus

Doppelklick auf das ApERA-TooL.exe Assembly

ERATooL startet auf Der File- und Group-Browser zeigen

keine eingelesenen Files an Panel2 ist leer Folgende Menüs dürfen aktiv sein:

File/Open + File/Exit + Maintenan-ce/Logging + Help/About. Alle anderen Menüpunkte müssen grau hinterlegt (de-aktiviert) sein

das „Open“ Shortcut Symbol mit Tool-tip ist aktiv. Alle anderen Shortcuts müs-sen grau hinterlegt (deaktiviert) sein

Die Aktion liefert die beschriebenen Ergebnisse im Soll

OK

6.2.1.3 Testszenario 2: Wahl verschiedener Logging Device

Testfall Beschreibung Aktionen Soll Ist Befund TF_0002 Benutzer startet

ERATooL Applikation im Release Modus

Lösche zuerst allfällig vorhandenes Logfile im OrdnerC:\Temp\ERATooL_Logging

Im Ordner„C:\Temp\ERATooL_Logging“ ist ein Logfile (mit Endung *.log) vorhanden, welches den Aufstartvorgang aufge-zeichnet hat


ERATooL startet auf

Die Aktion liefert die beschriebenen Ergebnisse im Soll

OK


TF_0003 Benutzer deaktiviert

Logging Doppelklick auf das ApERA-

TooL.exe Assembly Menü Maintenance/Logging wähle Radio Button „Disable Log-

ging“ und Taste „OK“ Führe TF_1300 „Daten einlesen“

aus


Die Aktionen liefern die beschriebenen Ergebnisse im Soll

Im Ordner „C:\Temp\ERATooL_Logging“ dürfen seit dem Aufstartvorgang keine weite-ren Logging-Einträge aufgeführt sein, da das Logging deaktiviert wurde

OK

TF_0004 Benutzer will in ein File loggen

Führe TF_0003 „Benutzer deakti-viert Logging“ aus

Menü Maintenance/Logging wähle Radio Button „Log to file“

und Taste „OK Führe TF_1300 aus „Daten einle-

sen“ aus



Im Ordner „C:\Temp\ERATooL_Logging“ muss ein Logfile vorhanden sein (mit Endung *.log), welches zusätzliche Logging-Einträge vom TF_1300 enthält

OK

6.2.1.4 Testszenario 3: Einsicht der Software Version von ERATooL

Testfall Beschreibung Aktionen Soll Ist Befund TF_0005 Benutzer will die

Software Versionvon ERATooL in Er-fahrung bringen


Menü Help/About Selektiere Erowa Web-Adresse Nach Ansicht des Dialogs, die-

sen mit Button „OK“ wieder verlas-sen

Dialog zeigt Main-, Applikation- und Framework-Softwareversion

Klick auf die EROWA Internetadresse öffnet im Standard Web-Browser die EROWA Home Site www.erowa.com

Nach Drücken des „OK“-Button soll der About Dialog wieder verschwinden


OK

http://www.erowa.com/


6.2.1.5 Testszenario 4: Applikation beenden

Testfall Beschreibung Aktionen Soll Ist Befund TF_0006 Benutzer beendet

die ERATooL Appli-kation


Selektiere File/Exit

ERATooL Applikation wird been-det

Die Aktion liefert die be-schriebenen Ergebnisse im Soll

OK

TF_0007 Benutzer beendetdie ERATooL Appli-kation


Selektiere „x“ an der Titelleiste zum Schliessen der Applikation

ERATooL Applikation wird been-det

Die Aktion liefert die be-schriebenen Ergebnisse im Soll

OK

6.2.2 Testsequenz 1300: Daten einlesen


• TF_0001 (Applikation starten) erfolgreich ausgeführt

6.2.2.2 Testszenario 1: Daten einlesen

Testfall Beschreibung Aktionen Soll Ist Befund TF_1300 Benutzer will Be-

schreibungsfile und Chuck-Parameterfile in ERATooL einlesen

Selektiere den Menüpunkt „Open…“ Selektiere bei der Auswahl der physikalische

Datenablage des Beschreibungsfile „Description file is on local disk“ und drücke auf den Button „Next“

Selektiere das Beschreibungsfile „Parameter-Description_V02_TestingFile_valid_ERM_V520.xml „ und drücke auf den Button „Open“

Selektiere bei der Auswahl der physikalische Datenablage der Parameterfiles „Parameter file(s) are located on local disk“ und drücke auf den But-ton „Next“

Selektiere das Parameterfile „ChuckCon-fig_TestingFile_valid_ERM_V520.dat“ und drücke auf den Button „Öffnen“

Bestätige Meldung „Description and parameter files have been successfully read in“ mit Button „OK“, dass die Files erfolgreich eingelesen worden sind

Beschreibungs- und Parameterfile konnte erfolgreich eingelesen wer-den

Dialog mit der Information „Desc-ription and parameterfiles(s) have been successfully read in“ erscheint

File Browser zeigt im Tree-Ordner „Files/Parameter file(s) read in“ das File mit dem Namen „chuck“ an

File Browser zeigt im Tree-Ordner „Files/Description file read in“ das File mit dem Namen „Descriptio-nERMV520“ an

Group Browser zeigt das Root-Element „Groups“ und das Kindele-ment „chuck“ an

Folgende Menüs dürfen aktiv sein: File/Open + File/Save + Fi-

Die Aktio-nen liefern die be-schriebenen Ergebnisse im Soll

OK


le/Exit + Maintenance/Logging + Help/About. Alle anderen Menüpunk-te müssen grau hinterlegt (deakti-viert) sein

das „Open“ und „Save“ Shortcut Symbol mit Tooltip sind aktiv. Alle anderen Shortcuts müssen grau hin-terlegt (deaktiviert) sein.

TF_1300_b Benutzer will nur Chuck-Parameterfile in ERATooL einlesen

Selektiere den Open Tool Menüstrip (Open Shortcut Symbol)

Selektiere bei der Auswahl der physikalische Datenablage des Beschreibungsfile „No description file will be used“ und drücke auf den Button „Next“

Selektiere bei der Auswahl der physikalische Datenablage der Parameterfiles „Parameter file(s) are located on local disk“ und drücke auf den But-ton „Next“

Selektiere das Parameterfile „ChuckCon-fig_TestingFile_valid_ERM_V520.dat“ und drücke auf den Button „Open“

Bestätige Meldung „Parameter file(s) have been successfully read in“ mit Button „OK“, dass die Pa-rameterfiles erfolgreich eingelesen worden sind

Parameterfile konnte erfolgreich eingelesen werden

Dialog mit der Information „Pa-rameter files(s) have been success-fully read in“ erscheint

File Browser zeigt im Tree-Ordner „Files/Parameter file(s) read in“ das File mit dem Namen „chuck“ an

File Browser zeigt im Tree-Ordner „Files/No description file read in“ an

Group Browser zeigt Text „Tree View not available“

Folgende Menüs dürfen aktiv sein: File/Open + File/Save + Fi-le/Exit + Maintenance/Logging + Help/About. Alle anderen Menüpunk-te müssen grau hinterlegt (deakti-viert) sein

das „Open“ und „Save“ Shortcut Symbol mit Tooltip sind aktiv. Alle anderen Shortcuts müssen grau hin-terlegt (deaktiviert) sein.

Die Aktio-nen liefern die be-schriebenen Ergebnisse im Soll

OK


6.2.3 Testsequenz 1100: Konfiguration darstellen


• TF_1300 (Daten einlesen) erfolgreich ausgeführt

6.2.3.2 Testszenario 1: Konfiguration in Tabelle darstellen

Testfall Beschreibung Aktionen Soll Ist Befund TF_1110 Benutzer will ein-

gelesene Konfigu-ration in Tabelle darstellen

Selektiere die „File Browser“ Karteikarte Selektiere im File-Browser TreeView unter „Fi-

les/Parameter file(s) read in“ das File Symbol „chuck“

eingelesene chuck-Konfiguration wird in einer Tabelle dargestellt.

Die Darstellung erscheint im Main Window (Panel2)

Die Aktionen liefern die be-schriebenen Ergebnisse im Soll

OK

6.2.3.3 Testszenario 2: Konfiguration in Baumstruktur darstellen


die detaillierten Angaben einesParameters be-trachten

Selektiere die „Group Browser“ Karteikarte

Expandiere im Group-Browser TreeView den Kno-

ten „Groups/chuck/Chuck2“ Selektiere im Group-Browser TreeView den Kind-

Knoten „Groups/chuck/Chuck2/ChuckType“

alle verfügbaren Angaben zum selektierten Kind-Knoten „Chuck-Type“ werden im Detail-Dialog dar-gestellt (Bild, Textbeschreibung und Werte)

Die Darstellung erscheint im Main Window (Panel2)

Die Aktionen liefern die be-schriebenen Ergebnisse im Soll

OK


6.2.4 Testsequenz 1200: Parameter editieren


• Für Testszenario 1: TF_1110 (Konfiguration in Tabelle darstellen) erfolgreich ausgeführt • Für Testszenario 2: TF_1120 (Konfiguration in Baumstruktur darstellen) erfolgreich ausgeführt

6.2.4.2 Testszenario 1: Parameter in Tabelle editieren

Testfall Beschreibung Aktionen Soll Ist Befund TF_1210 Benutzer will eine

tabellarisch darge-stellte Konfigurati-on editieren

Suche folgende Zeile: - PARA: P101 / SET: 004 / VALUE: 000 / MIN: 000 / MAX: 026 / COMMENT:

Selektiere in der gesuchten Zeile die Kolonne „VALUE“ mit einem Doppelklick

Ändere den Wert auf 3 Auf der linken Tabellenumrandung wird aus dem

Dreieck-Symbol ein Stift-Symbol, welches die Editie-rung des Werts signalisiert

Bestätige Editierung mit der „Enter“ Taste

Die Tabelle hat den editieren Wert übernommen

Die Aktionen liefern die beschriebe-nen Ergeb-nisse im Soll

OK

6.2.4.3 Testszenario 1: Parameter in Baumstruktur editieren

Testfall Beschreibung Aktionen Soll Ist Befund TF_1220 Benutzer will den

Wert eines, im Detail-Dialog dar-gestellten, Parame-ters editieren

Selektiere im Group-Browser TreeView den Kind-Knoten „Groups/chuck/Chuck2/ChuckType“

Selektiere die DropDown Liste des Value-Eingabefenster

Ändere den Wert auf „PC210“

Der gewünschte Wert in der DropDown List konnte selektiert wer-den

Die ausgegraute Textbox unter-halb der Wertanzeige hat den Wert 3 angenommen


OK


6.2.5 Testsequenz 1400: Daten ausgeben


• TF_1220 (Parameter in Baumstruktur editieren) erfolgreich ausgeführt

6.2.5.2 Testszenario 1: Daten Ausgeben


aktuelle ChuckKonfiguration in ein ASCII-Parameterfile schreiben

Bestätige den „Export Parameter Group“ Dialog mit dem Button „Next“ ohne eine Veränderung vor-zunehmen. Somit werden alle verfügbaren Parame-tergruppen in Parameterfiles geschrieben.

Selektiere den Menüpunkt „Save…“

Beachte: Es wird nur das Chuck-File mit einer akti-ven Check-Box dargestellt (gemäss Testvorgaben), somit kann auch nur dieses selektiert und ge-schrieben werden

Selektiere bei der Auswahl des Speicherorts der Parameterfiles „Parameter file(s) will be saved on local disk“ und drücke auf den Button „Next“

Wähle im File-Save Dialog den Pfad des Spei-cherorts aus

Bestätige die Angabe des Pfads mit dem Button „OK“

Bestätige den Dialog „Parameter file(s) have been successfully written“ mit Button „OK“, dass das File erfolgreich geschrieben worden ist

Die Konfigurationsdaten des Chuck-Parameterfile konnte erfolg-reich geschrieben werden

Dialog mit der Information „Pa-ramterfile(s) have been successfully written“ erscheint

Als Kontrolle kann das eingelese-ne mit dem geschriebenen Parame-terfile mit dem Tool „Beyond Compa-re“ einfach verglichen werden. Die beiden Files müssen, bis auf die vor-genommenen Änderungen identisch sein. D. h. die Zeile: - PARA: P101 - SET: 004 muss neu den Wert 3 in der VALUE Kolonne besitzen


OK


6.3 Testen mit Testing-Framework NUnit 2.4.734

6.3.1 Motivation

Da ich mich noch nie mit einem Testing Framework auseinander gesetzt habe, wollte ich dies in meiner Diplomarbeit exemplarisch einsetzen. Nach Recherchen im Internet bin ich auf NUnit ge-stossen, welches ein geeignetes Testing Framework für .NET Anwendungen ist. Mir ging es darum, erste Erfahrungen mit automatisierten Tests zu sammeln.

6.3.2 Allgemeines

NUnit ist ein Unit Testing Framework für alle .NET Programmiersprachen. Es wurde in seiner Initi-alversion von JUnit portiert und die aktuelle Version 2.4.7 ist inzwischen der fünfte Release. Das Testing Framework ist vollständig in C# geschrieben, um auch alle .NET Sprachkonstrukte zu tes-ten. NUnit eignet sich hervorragend für White-Box bzw. Unit Testing.

Abbildung 60: GUI des Testing Framework NUnit

Wie aus Abbildung 60 ersichtlich ist, können über das NUnit GUI verschiedene Informationen an-gezeigt werden. Diese können mit den Karteikarten im unteren linken Menübereich selektiert wer-den.

34 Siehe [NUnit]


6.3.3 Add-in für Visual Studio 2005

Nach einigen Internet Recherchen bin ich auf das add-in von TestDriven.NET35 für das Microsoft Visual Studio 2005 gestossen. Dies erlaubt dem Entwickler die NUnit Tests im Visual Studio mit einem Mausklick zu starten.

Abbildung 61: Starten der Tests aus der Entwicklungsumgebung VS2005

6.3.4 Umsetzung

6.3.4.1 NUnit einbinden

Für den umfangreichen und fehleranfälligen Use Case „1300 Daten importieren“ habe ich automa-tisierte Tests mit NUnit geschrieben. Dazu habe ich in der Solution ein neues Projekt mit dem Na-men „ERATooL Testing“ eröffnet. Um die Funktionalitäten von NUnit zu nutzen, muss die Bibliothek nunit.framework.dll herunter geladen und als Referenz ins Projekt eingebunden werden.

6.3.4.2 Test Case definieren

Damit NUnit die geschriebenen Testklassen auch als solche erkennt, muss man die Klassen, Me-thoden und Attribute mit vordefinierten Tags versehen. Diese werden nachfolgend in der Abbildung 62 aufgeführt und erläutert:

35 Siehe [TestDriven.NET Add-in für VS2005]


Mit dem Attribut TestFixture werden Klassen deklariert, welche Test Cases in sich haben. [TestFixture] public class CTestCase1300DataImport Das Attribut SetUp muss in jeder Testklasse vorhanden sein und wird vor jeder einzelnen Test-ausführung durchlaufen. Diese Methode muss in einer Testklasse vorhanden sein, aber sie darf nur einmal definiert werden. [SetUp] public void Init() Das Attribut TearDown muss in jeder Testklasse vorhanden sein und wird nach jeder einzelnen Testausführung durchlaufen. Diese Methode muss in einer Testklasse vorhanden sein, aber sie darf nur einmal definiert werden. [TearDown] public void tearDown() Beispiel eines Test Case mit dem Attribut Test, welches ohne Exception ausgeführt werden muss, um den Test erfolgreich zu bestehen. /// <summary> /// Test case: Header of description file is valid /// </summary> [Test] public void tc1300_1_parseDescriptionFileHeaderWithValidFile() { string filePath = m_testPath + "ParameterDescription_ERS_V480.xml"; m_apModelController.parseDescriptionFileHeader(filePath); } Beispiel eines Test Case mit dem Attribut Test, in welchem die Exception CfwFileHeaerException geworfen werden muss, um den Test erfolgreich zu bestehen. /// <summary> /// Test case: Description file is no xml file /// </summary> [Test] [ExpectedException(typeof(CFwFileHeaderException))] public void tc1300_c2_parseDescriptionFileHeaderNoXmlFile() { string filePath = m_testPath + "NoXmlFile.doc"; m_apModelController.parseDescriptionFileHeader(filePath); }

Abbildung 62: Bedeutung und Verwendung der NUnit Test Tags


6.3.4.3 Tests ausführen

Jeder Test durchlebt immer den gleichen Ablauf:

• 1.) Ausführung der mit dem Attribut SetUp gekennzeichneten Methode Vorbereitung der Test Infrastruktur (Bereitstellung der Ausgangslage und Erzeugung der Objekte)

• 2.) Eigentliche Ausführung der mit dem Attribut Test gekennzeichneten Methode Aus-führung des Tests

• 3.) Ausführen der mit dem Attribut TearDown gekennzeichneten Methode Abbauen der aufgebauten Test Infrastruktur (zerstören der aufgebauten Objekte)

Die so definierten Tests können per Mausklick ausgeführt werden. Bei Code Änderungen von be-reits realisierten Funktionen kann somit sofort eruiert werden, ob die Code-Änderungen die beste-henden Regeln (Business Rules) verletzen oder nicht. Diese so genannten Regressionstests sind sehr mächtig und hilfreich. Es hat sich gezeigt, dass ich in relativ kurzer Zeit, einfache, automatisierte Tests erstellen konnte. Dank diesen Tests konnte ich einige Fehler lokalisieren. Zudem können einmal definierte Testfälle immer wieder als Regressionstests durchgespielt werden.

B

esprechung Seite 102 / 124

7 Besprechung

7.1 Allgemeines Beachte: Im Rahmen der Master Thesis wurden die nachfolgend aufgelisteten Anforderungen lediglich für die Chuck Parametergruppe realisiert. Die drei anderen exemplarisch implementierten Parameter-gruppen (General, Magazin und Pfad) sind lediglich ein Zusatz. Sie sollen zeigen, dass das Einlesen, Ausgeben und Editieren nicht nur für die Chuck-Parametergruppe, sondern auch für alle anderen Parametergruppen-Typen funktioniert. Im Ge-gensatz zur Chuck-Parametergruppe haben die Parametergruppen General, Magazin und Pfad nicht den Anspruch, in ihrer Darstellung und Funktionalität fehlerfrei zu sein.

7.1.1 Priorität

Die nachfolgend aufgeführte Priorität (Prio) legt die Verbindlichkeit der Realisierung fest:

• Priorität 1 Dies ist zwingend innerhalb der Master Thesis zu realisieren • Priorität 2 Dies ist nach Möglichkeit (nicht zwingend) innerhalb der Master Thesis zu rea-

lisieren • Priorität 3 Dies kann nach der Master Thesis in einem späteren Release realisiert werden

7.1.2 Status

Nachfolgend wird jede Anforderung mit einem Status versehen, um den Erfüllungsgrad jeder ein-zelnen Anforderung zu deklarieren:

• erfüllt: Anforderungen ist erfüllt • teilweise erfüllt: Anforderung ist nur teilweise erfüllt • nicht erfüllt: Anforderung ist nicht erfüllt

7.2 Abweichungen vom Pflichtenheft Es werden nur diejenigen Anforderungen aufgeführt, welche die Priorität 1 besitzen und nicht den Status „erfüllt“ erhalten haben.

ID Anforderung Status Comment TA3102 Logging ein- bzw. ausschal-

ten soll erst bei Neustart übernommen werden

teilweise erfüllt

Die Änderung wird sofort übernommen. Bei einem Neustart von ERATooL wird die Einstellung vor der Beendigung des Tools nicht übernommen. Beim Applikationsstart im Release Mode wird per Default immer in ein File geloggt

TA3103 Per Default ist das Logging deaktiviert

nicht erfüllt Sinnvollerweise ist das Logging im Re-lease-Mode immer aktiv

TA3104 Per Default soll in ein File geloggt werden

teilweise erfüllt

Im Release-Mode wird in ein File, im De-bug-Mode auf die Konsole geloggt

NA7201 Installationsanleitung von ERATooL

teilweise erfüllt

Für die Installation habe ich lediglich ein ReadMe-File geschrieben

Besprechung Seite 103 / 124

7.3 Status der Anforderungen basierend aus dem Pflichtenheft

7.3.1 Applikation

ID Prio Anforderung Status Comment FA1000 Applikation FA1100 Konfiguration darstellen FA1101 1 Der Anwender kann die einzulesenden Parameter- und Beschreibungsfiles selektieren, welche

nachfolgend dargestellt werden sollen erfüllt

FA1102 1 Die selektierten Files sollen von ERATooL eingelesen werden können erfüllt FA1103 1 Für den Anwender muss ersichtlich sein, welche Roboter Parameterfiles eingelesen worden

sind erfüllt

FA1105 1 Die Roboter-Parameter sollen gruppen-orientiert dargestellt werden können erfüllt FA1108 1 Die Roboter-Parameter sollen tabellarisch dargestellt werden erfüllt FA1110 1 Beim Selektieren eines Parameters sollen alle verfügbaren Infos angezeigt werden erfüllt FA1104 2 Der Anwender soll wählen können, ob die Roboter Parameter komponenten- oder gruppen-

orientiert dargestellt werden sollen teilweise

erfüllt Die Konfiguration kann nicht Komponenten-orientiert dar-gestellt werden

FA1107 2 Der Anwender soll wählen können, wie (z. B. tabellarisch, in Baumstruktur usw.) die Konfigu-ration dargestellt werden soll

erfüllt

FA1109 2 Die Roboter-Parameter sollen in einer hierarchischer Baumstruktur (ähnlich einem XML-Tree) dargestellt werden können

erfüllt

FA1111 2 Der Anwender soll bei der tabellarischen Darstellung die Möglichkeit haben, vordefinierte Kriterien bezüglich der Auflistung der Parameter auszuwählen

teilweise erfüllt

Die Tabellen Spalten können alphabetisch und numerisch sortiert werden

FA1112 2 Der Anwender soll bei der hierarchischen Darstellung die Möglichkeit haben, vordefinierte Kriterien bezüglich der Auflistung der Parameter auszuwählen

nicht erfüllt

FA1106 3 Die Roboter-Parameter sollen komponenten-orientiert dargestellt werden können nicht erfüllt Die Konfiguration kann nicht Komponenten-orientiert dar-gestellt werden

FA1200 Roboter parametrieren FA1214 1 Editierbare Parameter Werte werden gemäss ihrem Wertebereich geprüft (sofern ein Werte-

bereich definiert ist) und Änderungen nur bei deren Gültigkeit akzeptiert erfüllt

FA1202 1 Wird eine bestehende Konfiguration editiert, muss der Anwender die Möglichkeit haben, die zu editierenden Parameter Files zu selektieren

erfüllt

FA1203 1 Die selektierten Files sollen von ERATooL eingelesen werden können erfüllt FA1204 1 Für den Anwender muss ersichtlich sein, welche Roboter Parameterfiles eingelesen worden

sind erfüllt


FA1206 1 Die Roboter-Parameter sollen gruppen-orientiert konfiguriert werden erfüllt FA1209 1 Die Roboter-Parameter sollen in tabellarischer Darstellung konfiguriert werden können erfüllt FA1211 1 Beim Selektieren eines Parameters sollen alle verfügbaren Infos angezeigt werden erfüllt FA1201 2 Der Anwender soll eine bestehende Konfiguration editieren oder eine Neukonfiguration des

Robotersystems durchführen zu können teilweise

erfüllt Eine Neukonfiguration kann momentan nicht durchge-führt werden

FA1208 2 Der Anwender soll wählen können, in welcher Darstellungsart (z. B. tabellarisch, in Baum-struktur usw.) konfiguriert werden soll

erfüllt

FA1210 2 Die Roboter-Parameter sollen in einer hierarchischen Baumstruktur (ähnlich einem XML-Tree) Darstellung konfiguriert werden können

erfüllt

FA1212 2 Der Anwender soll beim tabellarisch dargestellten Konfigurieren die Möglichkeit haben, vorde-finierte Kriterien bezüglich der Auflistung der Parameter auszuwählen.

teilweise erfüllt

Die Tabellen Spalten können alphabetisch und numerisch sortiert werden

FA1213 2 Der Anwender soll beim hierarchisch dargestellten Konfigurieren die Möglichkeit haben, vor-definierte Kriterien bezüglich der Auflistung der Parameter auszuwählen

nicht erfüllt

FA1215 2 Es soll möglich sein, nach bestimmten Parameter Werten suchen zu können. Die gefundenen Resultate sollen dargestellt werden können

nicht erfüllt

FA1216 2 Es soll möglich sein, nach bestimmten Parameter Werten zu suchen und diese mit bestimm-ten Werten ersetzen zu können

nicht erfüllt

FA1205 3 Der Anwender soll wählen können, ob die Roboter Parameter komponenten- oder gruppen- orientiert konfiguriert werden sollen

teilweise erfüllt

Die Konfiguration kann nicht Komponenten-orientiert dar-gestellt werden

FA1207 3 Die Roboter-Parameter sollen komponenten-orientiert konfiguriert werden können nicht erfüllt Die Konfiguration kann nicht Komponenten-orientiert dar-gestellt werden

FA1300 Daten einlesen FA1301 1 ERATooL soll die Möglichkeit bieten, vor dem Einlesen von Roboter Parameterfiles dessen

Gültigkeit zu überprüfen erfüllt

FA1302 1 ERATooL soll die Möglichkeit bieten, vor dem Einlesen von Parameter Beschreibungsfiles des-sen Gültigkeit zu überprüfen

erfüllt

FA1303 1 ERATooL muss Roboter Parameterfiles einlesen können erfüllt FA1304 1 ERATooL muss Roboter Parameter Beschreibungsfiles einlesen können erfüllt FA1305 1 Der Anwender soll wählen können, welche Roboter Parameter Files eingelesen werden sollen erfüllt FA1306 1 Können vollständige Roboter Parameterfiles oder einzelne Werte innerhalb der Parameterfiles

nicht eingelesen werden, soll dies für den Anwender ersichtlich sein erfüllt

FA1307 1 Für den Anwender muss ersichtlich sein, welche Roboter Parameterfiles eingelesen worden sind

erfüllt

FA1308 1 Roboter Parameterfiles müssen von einem lokalen (Desktop/Laptop) oder remote (Netzlauf-werk) Laufwerk eingelesen werden können

erfüllt


FA1310 1 Können vollständige Parameter Beschreibungsfiles oder einzelne Werte innerhalb der Be-

schreibungsfiles nicht eingelesen werden, soll dies für den Anwender ersichtlich sein erfüllt

FA1311 1 Für den Anwender muss ersichtlich sein, welche Parameter Beschreibungsfiles eingelesen worden sind

erfüllt

FA1312 1 Parameter Beschreibungsfiles müssen von einem lokalen- (Desktop/Laptop) oder remote- (Netzlaufwerk) Laufwerk eingelesen werden können

erfüllt

FA1309 3 Roboter Parameterfiles sollen von der Roboter Steuerung direkt eingelesen werden können nicht erfüllt FA1313 3 Parameter Beschreibungsfiles können von der Roboter Steuerung direkt eingelesen werden nicht erfüllt FA1400 Daten ausgeben FA1401 1 Aus den in ERATooL eingelesenen Parameter sollen gültige Roboter Parameterfiles erzeugt

werden können erfüllt

FA1402 1 Roboter Parameterfiles sollen auf einem lokalen (Desktop/Laptop) oder remote (Netzlauf-werk) Laufwerk erzeugt werden können

erfüllt

FA1403 3 Ein Roboter Parameterfile soll auf der Roboter Steuerung erzeugt werden können nicht erfüllt


7.3.2 Services-Framework

ID Prio Anforderung Status Comment TA3000 Services-Framework

TA3100 Logging TA3101 1 Das Services-Framework soll einen einheitlichen Logging-Mechanismus zur Verfügung stel-

len erfüllt

TA3102 1 Der Logging-Mechanismus muss ein- und ausgeschaltet werden können. Die Änderung wird nur mit einem Neustart von ERATooL übernommen

teilweise erfüllt

Die Änderung wird sofort übernommen. Bei einem Neustart von ERATooL wird die Einstellung vor der Been-digung des Tools nicht über-nommen. Beim Applikations-start im Release Mode wird per Default immer in ein File geloggt

TA3103 1 Standardmässig soll das Logging deaktiviert sein nicht erfüllt Sinnvollerweise ist das Log-ging im Release-Mode immer aktiv

TA3104 1 Standardmässig soll in ein File geloggt werden teilweise erfüllt

Im Release-Mode wird in ein File, im Debug-Mode auf die Konsole geloggt

TA3105 1 Der Dateiname und der Speicherort des Log-Files müssen gewählt werden können erfüllt Dies kann im XML-Logger Konfigurationsfile angepasst werden

TA3106 1 Die Grösse des Log-Files soll gewählt werden können erfüllt Dies kann im XML-Logger Konfigurationsfile angepasst werden

TA3108 1 Folgende Log-Stufen sollen unterstützt werden: INFO, WARNING, ERROR, FATAL erfüllt TA3110 1 Jeder Log-Eintragsoll einen Zeitstempel beinhalten erfüllt TA3107 2 Das Services-Framework soll die Möglichkeit bieten, auf verschiedene Devices zu loggen erfüllt Es kann in ein File oder auf

die Konsole geloggt werden TA3109 2 Das Logging soll in noch zu definierende Module unterteilt werden. Somit soll es möglich

sein, gezielt Aktivitäten interessierender Module ein- oder auszuschalten nicht erfüllt

TA3200 File Handling TA3201 1 Das Services-Framework soll Files einlesen können erfüllt TA3202 1 Das Services-Framework soll Files parsen und die Daten an die Applikation weiterleiten kön-

nen erfüllt

TA3203 1 Das Services-Framework soll, aus zur Verfügung gestellten Daten, Files erzeugen können erfüllt


TA3204 1 Das Services-Framework soll die Möglichkeit bieten, Files vor dem Einlesen auf dessen Gül-

tigkeit zu überprüfen erfüllt

TA3205 1 Kann ein File nicht korrekt geparst werden, soll dies ersichtlich sein erfüllt TA3300 Daten Aufbereitung TA3301 2 Es soll möglich sein, Daten nach vorgegebenen Suchmustern (Zahlen, Text) zu durchsuchen

und die gefunden Resultate aufzuführen nicht erfüllt

TA3302 2 Es soll möglich sein, Daten nach vorgegebenen Suchmustern (Zahlen, Text) zu durchsuchen und mit definierten Werten zu ersetzen

nicht erfüllt

TA3303 2 Es soll möglich sein, Daten nach vorgegebenen Kriterien zu sortieren nicht erfüllt TA3400 Kommunikation TA3401 1 Es soll möglich sein, Daten über ein lokales (PC/Laptop) oder remote Laufwerk (Windows-

Filesystem) zu transferieren (einlesen / ausgeben) zu können erfüllt

TA3402 3 Es soll möglich sein, Daten über das FTP-Protokoll zu transferieren (einlesen / ausgeben) zu können

nicht erfüllt

TA3403 3 Der Datenaustausch mit der Roboter Steuerung über das FTP-Protokoll soll mit einem Be-nutzernamen und Passwort gesichert werden

nicht erfüllt

TA3500 Daten TA3501 1 Die einzulesenden Parameterfiles entsprechen einem definierten Fileaufbau erfüllt TA3502 1 Die Anreicherung der Information der Roboter Parameter Daten soll mit einem Parameter

Beschreibungsfile realisiert werden erfüllt

TA3503 1 Das Beschreibungsfile muss einen Header und einen Body aufweisen erfüllt TA3504 1 Das Parameter Beschreibungsfile muss Kennungsfelder haben, um eine Verifizierung des

Files vornehmen zu können erfüllt


7.3.3 Produkt-Qualität

ID Prio Anforderung Status Comment NA5000 Produkt-Qualität

NA5100 Funktionalität NA5101 1 Die von der Roboter Steuerung erzeugten ASCII-Parameterfiles müssen von ERATooL kor-

rekt eingelesen werden können erfüllt

NA5102 1 Die von der Roboter Steuerung erzeugten Parameter Beschreibungsfiles müssen von ERA-TooL korrekt eingelesen werden können

erfüllt

NA5103 1 Die von ERATooL erzeugten ASCII-Parameterfiles müssen von der Roboter-Applikation kor-rekt eingelesen werden können

erfüllt

NA5200 Zuverlässigkeit NA5201 1 In ERATooL editierbare Parameter-Werte werden gemäss ihrem Wertebereich geprüft (so-

fern ein Wertebereich definiert ist) und Änderungen nur bei deren Gültigkeit akzeptiert erfüllt

NA5202 3 ERATooL gibt auf fehlerhafte und ungenügende Parameter-Werte Eingaben eine definierte Antwort

erfüllt

NA5300 Benutzbarkeit NA5301 1 Die Anwender von ERATooL sind mit dem Anwendungsgebiet sehr gut vertraut. Somit stellt

das Tool betreffend der Anwendungs-Domäne kein Hilfemenü zur Verfügung erfüllt

NA5303 1 Alle GUI-Elemente (Menü, Dialoge, Bezeichnungen) werden lediglich in Englisch bezeichnet erfüllt NA5302 2 Mit Tooltips werden kleine Hilfestellungen bezüglich der Bedienung von ERATooL vorgese-

hen erfüllt Tooltips habe ich lediglich für

die aktiven Shortcuts „Open“ und „Save“ erstellt

NA5304 2 Der Anwender soll in der Lage sein, ERATooL nach einer 2-stündigen Schulung selbststän-dig bedienen zu können

erfüllt Muss noch ausgeführt wer-den. Diese Anforderung sollte sicherlich zu erfüllen

NA5305 2 Die Bedienung von ERATooL soll grundsätzlich an Standard SW-Produkte (MS Office An-wendungen, …) angelehnt sein (Shortcuts, Tooltips und andere Benutzungselemente)

erfüllt

NA5306 2 Die Grundelemente und der Grundaufbau der Bedienoberfläche soll von allen Use Cases benutzt werden können

erfüllt

NA5400 Erweiterbarkeit NA5401 1 Neue Use Cases sollen effizient realisiert werden können erfüllt Die Architektur und das De-

sign erlauben ein effizientes Einfügen von neuen Use Cases

NA5402 1 Neue Use Cases sollen einfach realisiert werden können erfüllt Durch die saubere Trennung von der Schichten und der konsequenten Umsetzung des MVC-Patterns können


neue Use Cases einfach reali-siert werden

NA5403 1 Neue Use Cases sollen bestehende Dienste des Services-Framework nutzen können erfüllt Grundsätzlich können alle Services (Logging, FilePro-cessor, ..) von allen Applika-tionsmodulen genutzt wer-den

NA5500 Konfigurierbarkeit NA5502 1 Die Aktualität von ERATooL muss mit wenig Aufwand gewährleistet werden können erfüllt Mit der Auslagerung der häu-

fig ändernden Parameter-Beschreibungen in ein edi-tierbares Beschreibungsfile, konnte die Dynamik aus der Applikation entfernt werden

NA5501 2 ERATooL soll möglichst wenig Business Know-how bezüglich der Roboter Anwendung in Form von Code enthalten

erfüllt Alle Angaben zu den Parame-tern sind in das Beschrei-bungsfile ausgelagert. Somit ist im Code sehr wenig Pa-rameter „Business Know-how“ vorhanden. Diese Info wird aus dem Beschreibungs-file bezogen


7.3.4 Prozess-Qualität

ID Prio Anforderung Status Comment NA7000 Prozess-Qualität

NA7100 Realisierung und Entwicklung NA7101 1 ERATooL soll auf dem Microsoft .NET Framework Version 2.0 entwickelt werden erfüllt NA7102 1 ERATooL wird mit der Programmiersprache C# implementiert erfüllt NA7103 1 Als Entwicklungsumgebung wird Visual Studio 2005 Standard Edition verwendet erfüllt NA7104 1 Für die Modellierung der Software wird die UML 2.0 Notation verwendet erfüllt NA7105 1 Das Berichtwesen der Master Thesis wird in der Deutschen Sprache abgewickelt erfüllt NA7106 1 Die SW-Bezeichner im Source Code und die Source Code Beschreibung wird in Englisch

gehalten erfüllt

NA7107 2 Der Code soll im Visual Studio 2005 XML-basiert dokumentiert werden Jedes Element (Klasse, Methode, Attribute) muss beschrieben werden

erfüllt Für die Code-Dokumentation wurde NDoc2005 verwendet

NA7200 Dokumentation NA7201 1 Installationsanleitung von ERATooL teilweise

erfüllt Für die Installation habe ich lediglich ein ReadMe-File geschrieben

NA7202 2 Kurze ERATooL Benutzeranleitung nicht erfüllt NA7203 2 API-Beschreibung des Services-Frameworks nicht erfüllt

Pro

jekt Seite 111 / 124

8 Projekt

8.1 Projekt Ablauf

8.1.1 Meetings mit dem Experten

Folgende Themen wurden an den Meetings in Bern mit Herrn Prof. Urs Künzler besprochen: Meeting Datum Themen

1 09.04.08 Erstes Treffen und Kennen lernen / Besprechung des Ablaufs der Master Thesis / Besprechung des ersten Entwurfs des Pflichtenhefts

2 28.05.08 Besprechung der erstellten Analyse und einigen Design Modellen / Aufbau des XML-Beschreibungsfile / Datenstruktur

3 18.06.08 Abschlussbesprechung der Analyse und Design Phase / Präsentation des Haupt-Prototypen

4 21.08.08 Besprechung des Diplomberichts / Präsentation der fast fertig gestellten ERATooL Anwendung / Ablauf und Tätigkeiten für den Abschluss der Mas-ter Thesis

Projekt Seite 112 / 124

Abbildung 63: ERATooL Projektplan

8.1.1.1 Projekt Plan


8.1.2 Projekt Hilfsmittel

8.1.2.1 Tagebuch

Schon an der Fachhochschule habe ich während der Diplomarbeit ein Tagebuch über die realisier-ten Arbeiten geführt. Dies hat sich sehr bewährt und somit habe ich auch für diese Master Thesis ein Tagebuch geführt. Einerseits habe ich Projektkoordinaten wie Zeitaufwand, Art der geleisteten Arbeit und die Be-schreibung der Tätigkeit eingetragen. Zum anderen sind auch persönliche Aspekte wie Probleme, freudige wie enttäuschende Erkenntnisse und andere Ereignisse eingeflossen. Mit Hilfe des Tage-buchs kann der Ablauf der Diplomarbeit jederzeit nachvollzogen werden. Im Anhang ist das voll-ständige Tagebuch eingebunden.

8.1.2.2 Management Cockpit

Das Management Cockpit hat die eingetragenen Arbeitszeiten im Tagebuch getrennt nach Tätigkeit in einer Übersicht aufgeführt. Somit hatte ich jederzeit den Überblick der momentan geleisteten und der theoretisch zu leistenden Arbeitsstunden.

Abbildung 64: Management Cockpit mit Auflistung der Zeitaufwände

Abbildung 64 zeigt die Zeitaufwände der einzelnen Tätigkeiten. Aus diesen Daten ist ersichtlich, dass die Dokumentation (inkl. Projekt), die Analyse/Design-Phase und die Implementation je rund ein Drittel der aufgewendeten Zeit in Anspruch genommen haben. Bei kleinen Projekten wie dieser Master Arbeit ist dies typisch. Der Testaufwand war in Tat und Wahrheit grösser, da ein Teil des Testaufwands in den Aufwendungen der Implementation berück-sichtigt ist. Es gilt jedoch zu beachten, dass die einzelnen Zeitaufwände mit Vorsicht zu geniessen sind, da einige Aktivitäten nicht konsequent zugeordnet wurden. Zudem sind in dieser Darstellung die let-zen 2 Wochen der Master Thesis nicht aufgeführt.


8.1.2.3 Statusbericht

Während der Master Thesis habe ich an folgenden Kalenderwochen einen Statusbericht an den Experten Prof. Urs Künzler und den Betreuer Simon Kuster zugesandt:

• Kalenderwoche 11 • Kalenderwoche 13 • Kalenderwoche 14 • Kalenderwoche 20 • Kalenderwoche 27 • Kalenderwoche 32

Der Statusbericht umfasste ein A4 Seite und beinhaltete kurz und bündig den Stand der aktuellen und geplanten Arbeiten. Somit wurde der Experte zyklisch informiert und konnte den Fortschritt der Master Thesis verfolgen. Aus meiner Sicht war dies ein gutes Instrument, um mir und dem Experten ein Überblick der Ar-beiten zu verschaffen.

8.1.2.4 Pendenzen- und Risikoliste

Am Anfang der Master Thesis habe ich eine Pendenzen- und eine Risikoliste erstellt. Die beiden Dokumente habe ich aber während der Arbeit nicht mehr gepflegt, da sie im Rahmen dieser Arbeit keinen Nutzen erbrachten.


8.2 Reflexion Als Spezialisierung habe ich im letzen Semester das Modul „Business Engineering“ gewählt, weil mich die Technik und Methodik in der Software Entwicklung sehr interessiert. In diesem Modul habe ich für jedes behandelte Thema (Business Modeling, Requirements Engineering, Testing …) eine Praxisarbeit erstellt, welche bewertet worden ist. Es war mir sehr wichtig, die gelernten As-pekte aus dem Spezialisierungsmodul so schnell wie möglich anwenden. Da hat sich die Master Thesis, als Spielwiese für diese Themen, gerade zu angeboten. Ich habe mir selbstständig eine Master Arbeit definiert, welche ich auf „der grünen Wiese“ begin-nen konnte. Einerseits wollte ich Erfahrungen in neuen Gebieten wie .NET, C#, XML und Imple-mentation eines Frameworks sammeln. Anderseits sollte aber auch eine brauchbare Anwendung entstehen, welche im Betrieb eingesetzt werden kann. Diese Doppelrolle als Auftraggeber und Umsetzer in einer Person war jedoch recht brisant, auch weil mein Betreuer die Firma verlies und ich somit noch mehr auf mich alleine gestellt war. Im Nachhinein war diese Doppelrolle und das isolierte Arbeiten vielleicht eine der grössten Schwierig-keiten der Master Thesis überhaupt. Glücklicherweise hat sich Simon Kuster spontan bereit erklärt, einzuspringen und mir als Betreuer zur Seite zu stehen. Er gab mir immer wieder hilfreiche .NET Tipps und hat sich sehr für mich en-gagiert Besten Dank. Auf jeden Fall habe ich beim Projektstart die Chance gepackt und die beteiligten Personen von Anfang an in den Entwicklungsprozess eingebunden: Ich habe mit den Anwendern ganz zu Beginn einen kreativ Workshop durchgeführt, um den Puls der Benutzer zu fühlen und die Bedürfnisse einzuholen. Obwohl keine revolutionären Erkenntnisse gewonnen werden konnten, war die Durch-führung des Workshops eine neue und gleichzeitig spannende Erfahrung. Der Vorbereitungs- wie auch Dokumentationsaufwand war jedoch recht erheblich. Mit diesen Erfahrungen habe ich in einem zweiten Schritt das Pflichtenheft aufgesetzt. Dies war ein langwieriger und aufreibender Prozess. Die simple Frage, welche Dienste das zu entwickelnde Ser-vices-Framework zur Verfügung stellen soll, war nur eine unter vielen Knacknüssen. Mir fehlte vielleicht manchmal die Erfahrung, diese Anforderungen präzise genug und praxisge-recht zu formulieren. Nichts desto trotz habe ich sehr viel profitiert und konnte eine ansprechende Anforderungsliste aufsetzen. Wie aus diesem Kapitel ersichtlich ist, habe ich die Projektplanung seriös und mit einigen Hilfsmit-teln abgewickelt. Da man sich im täglichen Berufsleben oft wenig Zeit für solche Projektbetrach-tungen nimmt, wollte ich dies in der Master Thesis tun. Leider konnte ich die ambitiös aufgestellte Planung (Basis Pflichtenheft) nicht einhalten. Ich hatte geplant bei der Realisierung zwei Iterati-onsschritte durchzuführen. Während der Analyse erlebte ich eine kurze Phase, in welcher ich mehr Probleme als Lösungen sah. Komplexe Themengebiete wie die Datenstruktur, das XML-Beschreibungsfile oder das Parsing, bereiteten mir doch einiges Kopfzerbrechen. Eine mögliche Lösung sah ich darin, Technologie-Prototypen einzusetzen, um die angesprochenen Herausforderungen möglichst rasch „quick and dirty“ anzugehen. Im Nachhinein hat sich die Er-stellung der Prototypen als eine entscheidende Tätigkeit der Master Thesis herausgestellt. Es war mir nun möglich, die Anforderungen in überblickbare Einheiten zu zerlegen und somit umzusetzen. Diese Prototypen haben aber mehr Zeit als geplant in Anspruch genommen, so dass ich erst Mitte Juni mit der Implementation beginnen konnte. Aus diesem Grund habe ich mich entschieden, nicht zwei sondern nur einen Iterationsschritt zu machen. Dies hat mich aber nicht beunruhigt, da ich mit Hilfe der Prototypen sehr genau wusste, wie ich die Anforderungen nun umsetzen konnte.


In der Realisierungsphase hat sich dann schliesslich gezeigt, dass sich die zusätzlich investierte Zeit in der Analyse und Design Phase gelohnt hat. Ich konnte einfach die Use Case Beschreibun-gen und die Ablaufdiagramme zur Hand nehmen und diese eins zu eins in C# Code umsetzen! Voilà, die Lehrbücher haben eben doch recht ;-) Diese Reflexion zeigt nur einige der illustren Aspekte der 6 Monate dauernden Master Thesis. Ich kann behaupten, dass ich sehr viel gelernt habe. Naja, das ist ja bei solchen Arbeiten immer so, aber dieses Mal habe ich auch einiges über mich gelernt. Ich war oft auf mich alleine gestellt und arbeitete 1 Tag pro Woche zu Hause. Dies hat mir sehr viel Selbstdisziplin und Willen abverlangt. Diese Master Thesis hat mir sehr viel Spass bereitet, manchmal aber auch Frust entlockt. Auf je-den Fall bin ich stolz auf das vorliegende Resultat und schreibe mit grosser Freude diese letzte Zeile! Es lebe ERATooL ;-) Peter Zurkirchen, Malters den 31.08.2008

Literatur- und Medienverzeichnis Seite 117 / 124

9 Literatur- und Medienverzeichnis

9.1 Literaturverzeichnis Requirements-Engineering und Management Chris Rupp / Hanser Verlag 4. Auflage 2007 ISBN-10: 3-446-40509-7 Analyse und Design mit UML 2.1 Bernd Oestereich / Oldenbourg Verlag 8. Auflage 2006 ISBN-10: 3-486-57926-6 Programmieren mit C# Jesse Liberty / O’Reilly 4. Auflage 2005 ISBN-10: 3-89721-415-6 Das C# 2005 Codebook Jürgen Bayer / Addison-Wesley 2005 ISBN-13: 978-3-8273-6118-9 .NET kompakt Ralf Westphal / Spektrum – Akademischer Verlag 2001 ISBN-10: 3-8274-1185-8 Developing Application Frameworks in .NET Xin Chen / Apress 1. Auflage 2004 ISBN-10: 1-59059-288-3 Framework Design Guidelines Krzysztof Cwalina and Brad Adams / Addison-Wesley 6. Auflage 2007 ISBN-10: 0-321-24675-6


9.2 Web-Links [Observer] Der Observer (Beobachter) ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung und gehört zu der Kategorie der Verhaltensmuster (Behavioural Patterns). Es dient zur Weitergabe von Änderungen an einem Objekten an von diesem Objekt abhängige Strukturen. Das Muster ist eines der so genannten GoF-Muster (Gang of Four). Quelle: http://de.wikipedia.org/wiki/Beobachter_%28Entwurfsmuster%29 [MVC] Model-View-Controller (MVC) bezeichnet ein Architekturmuster zur Strukturierung von Software-Entwicklung in die drei Einheiten Datenmodell (engl. Model), Präsentation (engl. View) und Pro-grammsteuerung (engl. Controller). Dieses Architekturmuster wird oft in interaktiven Systemen (GUI-Anwendungen) eingesetzt. Quelle: http://de.wikipedia.org/wiki/Model_View_Controller [Document-View] Document-View bezeichnet ein Architekturmuster zur Strukturierung von Software-Entwicklung in die zwei Einheiten Datenmodell (engl. Model) und Präsentation (engl. View). Die Programmsteue-rung (engl. Controller) ist in der Präsentation enthalten. Dieses Architekturmuster wird oft in inter-aktiven Systemen (GUI-Anwendungen) eingesetzt. Quelle: http://www.wikipedia.de [Singleton] Das Singleton (auch Einzelstück genannt) ist ein in der Softwareentwicklung eingesetztes Ent-wurfsmuster und gehört zur Kategorie der Erzeugungsmuster (engl. Creational Patterns). Es ver-hindert, dass von einer Klasse mehr als ein Objekt erzeugt werden kann. Dieses Einzelstück ist darüber hinaus üblicherweise global verfügbar. Das Muster ist eines, der von der so genannten Viererbande (GoF) publizierten Muster. Quelle: http://www.yoda.arachsys.com/csharp/singleton.html [Flyweight Design Pattern] Das Flyweight, selten auch Fliegengewicht genannt, ist ein Entwurfsmuster aus dem Bereich der Softwareentwicklung und gehört zu der Kategorie der Strukturmuster (Structural Patterns). Hat man alleine aufgrund einer zu großen Anzahl von Objekten zu hohe Speicherkosten, sollte man prüfen, ob der Objektzustand zu einem großen Teil in den Kontext verlagert (extrinsischer Zustand) werden kann. Je weniger Zustandsinformation beim Objekt verbleibt (intrinsischer Zu-stand), desto weniger Speicher wird dann insgesamt benötigt. Das Objekt wird dadurch zum „Flie-gengewicht“. Der intrinsische Zustand ist kontextunabhängig, wodurch das Fliegengewicht ge-meinsam nutzbar wird. Quelle: http://de.wikipedia.org/wiki/Flyweight [NDoc2005] NDoc ist ein Open Source Projekt welches bei SourceForge erhältlich ist. Das Tool kann für die Code Dokumentation von Anwendungen basierend auf dem .NET Framework 2.0 verwendet wer-den. NDoc selber wird kann nur für das .NET Framework 1.0 verwendet werden und wird nicht mehr weiter gepflegt. Quelle: http://sourceforge.net/projects/ndoc05/ [Using_NDoc2005] Die herunterladbare NDoc2005 Applikation kann ohne Modifikationen nicht verwendet werden. Ich habe in einem Web-Blog herausgefunden, was zu tun ist, dass NDoc2005 eingesetzt werden kann. Dies wird im nachfolgenden Link erläutert: Quelle: http://geekswithblogs.net/SudheersBlog/archive/2006/07/24/86146.aspx

http://de.wikipedia.org/wiki/Beobachter_%28Entwurfsmuster%29

http://de.wikipedia.org/wiki/Model_View_Controller

http://sourceforge.net/projects/ndoc05/


t

. - - r -

. .

[Log4Net] Log4Net ist ein Apache Logging Services Projekt, welches als Open Source Projekt genutzt werden kann. Log4Net ist ein Framework, welches zum Aufzeichnen von Anwendungsmeldungen in .NET verwendet werden kann. Quelle: http://logging.apache.org/log4net/index.h ml [CSV Dateiformat] Das Dateiformat CSV beschreibt den Aufbau einer Textdatei zur Speicherung oder zum Austausch einfach strukturierter Daten. Die Dateiendung CSV ist eine Abkürzung für Comma-Separated Va-lues (seltener Character Separated Values oder Colon Separated Values). Quelle: http://de.wikipedia.org/wiki/CSV_%28Dateiformat%29 [CsvWriter] Die Implementation dieser Klasse stammt aus einer Blog-Internetseite. Der Code hat im Wesentli-chen folgenden Zweck: Erzeugen eines Files im CSV-Format basierend auf Daten einer DataTable Datenstruktur. Für weitere Infos siehe Code und Beschreibung auf dem nachfolgend aufgeführten Internet Link. Quelle: http://knab ws/blog/index.php?/archives/3-CSV file-parser-and w iter-in-C Part-1.html [CsvParser] Die Implementation dieser Klasse stammt aus einer Blog-Internetseite. Der Code hat im Wesentli-chen folgenden Zweck: Einlesen eines Files im CSV-Format in eine DataTable Datenstruktur. Für weitere Infos siehe Code und Beschreibung auf dem nachfolgend aufgeführten Internet Link. Quelle: http://knab ws/blog/index.php?/archives/10-CSV-file-parser-and-writer-in-C-Part-2 html [NUnit] NUnit ist ein Unit Testing Framework für alle .NET Programmiersprachen. Es eignet sich hervorra-gend für White-Box bzw. Unit Testing Quelle: http://www.nunit.org/index.php [TestDriven.NET Add-In für VS2005] TestDriven.NET ist ein add-in in Visual Studio 2005, welches das Testing in die Entwicklungsumge-bung einbindet Quelle: http://www.testdriven.net/overview.aspx [XPath] Die XML Path Language (XPath) ist eine vom World Wide Web Consortium entwickelte Abfrage-sprache, um Teile eines XML-Dokumentes zu adressieren. XPath dient als Grundlage einer Reihe weiterer Standards wie XSLT, XPointer und XQuery. Quelle: http://de.wikipedia.org/wiki/XPath [DOM] Das Document Object Model (DOM) ist eine Programmierschnittstelle (API) für den Zugriff auf HTML- oder XML-Dokumente. Sie wird vom World Wide Web Consortium definiert. Im Sinne der objektorientierten Programmierung besteht das DOM aus einem Satz von Klassen zusammen mit deren Methoden und Attributen. Es erlaubt Computerprogrammen dynamisch den Inhalt, die Struktur und das Layout eines Dokuments zu verändern. Quelle: http://de.wikipedia.org/wiki/Document_Object_Model [log4net Apache Licence] Betreffend der Benutzung des log4net Projekts beachte nachfolgenden Link auf der Apache Seite. Quelle: http://logging.apache.org/log4net/license.html

Anhang Seite 120 / 124

10 Anhang

10.1 Übersetzung der Englischen Begriffe ab Design

Deutsch (Pflichtenheft, Analyse) Englisch (Design, Implementation) Anwender User Beobachter Observer Beobachteter Observable Daten Aufbereitung Data Processing Datenablage Data Repository Entwurfsmuster Design Pattern Namensraum Namespace Steuern Control Aufbereitung Processing


10.2 Anpassungen der Sourcen von NDoc2005 Nach dem Herunterladen der NDoc2005 Sourcen ist das Programm unter .NET 2.0 und dem Visual Studio 2005 nicht lauffähig. Die nachfolgenden Ausführungen stammen aus einem Blog, welcher die Problembehebung diskutiert (siehe http://geekswithblogs.net/SudheersBlog/archive/2006/07/24/86146.aspx). Recently I have been designing an Application Framework in .NET/ASP.NET 2.0. It went well and I was thinking of generating the documentation using Visual Studio 2005 as I used to do in VS 2003. I could not find something like “Build Comment Web Pages” under Tools and I realized that that option has been removed in 2005. MS talks of automating a lot of things and getting less and less work done for the developer and instead of improving that feature, it was totally removed. I searched for some alternatives and the following came as options:

• Write Custom XSL sheets • HelpStudio Lite from Innovasys that is shipped as a part of VS2005 SDK • NDoc for Visual Studio 2005

I found some examples that shows writing XSLs for generating the HTML files, but I felt that will be kind of an over kill. . I was looking for a solution that can generate HTML/CHM help files di-rectly from a Visual Studio 2005 Solution. The second option, HelpStudio Lite, the basic functionality is free when you install the 2005 SDK, but since it is not integrated with the VS 2005 Projects, it is of not much useFor this functionality, you have to buy the product Document! X from Innovasys. (http://www.innovasys.com/products/dx5/overview.asp). The single license version of this tool costs arnd $550. So I decided to try NDoc and it turned out to be working well. Here are the steps to get it working. Step 1 ***** Download the NDoc2005 Download the Beta Source code (as of now) from : http://prdownloads.sourceforge.net/ndoc05/ Please make sure to download the Source Code and not the binaries. The binaries on running gave me an error: Exception: System.IO.DirectoryNotFoundException Could not find a part of the path 'D:\Documenter\Msdn\xslt\namespace.xslt'. This is a known issue as a result of path hard coding. So the solution is to download the source code. Step 2 ***** Compile the NDoc2005 Source Code Step 3 ***** Generate Documentation

http://geekswithblogs.net/SudheersBlog/archive/2006/07/24/86146.aspx

http://www.innovasys.com/products/dx5/overview.asp

http://prdownloads.sourceforge.net/ndoc05/


Now DONOT try to run the NDoc Application by clicking F5. I did that initially and I had a solution that had around 5-6 projects. It was failing giving an error: Falied to load Assembly…blah..blah.. So the solution is to run the NDocGui.exe from NDoc2005\src\Gui\bin\Debug path. Now before starting the generation, you need to enable the XML document generation for each project in VS 2005(Project Properties->Build->Output->XMlDocumentationFile) Now add the decoration for you class and methods. I found some good article on this at: http://www codeproject.com/csharp/csharpcommentinganddocs asp. .which could be a good starting point. Now run the NDocGui.exe and specify ur solution name. It took a good amount of time to con-vert, but it is really fantastic. You get the MSDN style documentation, very neat and clean. Thanks a lot to NDoc..!! So happy documentation to all..!!! Update : 07-25-2006: --------------------------- I made a wrong statement in my last post: DONOT try to run the NDoc Application by clicking F5. So the solution is to run the NDocGui.exe from NDoc2005\src\Gui\bin\Debug path It is one and the same and I find, it was made bcose of some bad assumptions. But afterwards, it was failing to generate the documentation giving an exception : Falied to load Assembly It was failing inside: NDoc2005\src\Documenter\Msdn\MsdnHtmlUtilitiesV20.cs for the method : InitializeNamespaces() When I analyzed the code, I found that , it is failing to load the dependent assemblies of the as-sembly for which documentaion need to be generated. The reason is that the As-sembly.LoadWithpartialName(name) will try to load the assembly from the AppDomain’s bin direc-tory or from any of the configured path. This assembly is the one, whose path may be no way related to that of the NDocGui.exe. So I decided to use the following logic: Step 1: ****** Load the dependent assembly from the CodeBase of the main assembly. This assunes that the dependent assemblies will be there under the bin of the main assembly Step 2: ****** But this logic will fail for the GAC assemblies like mscorlib, System.Data which are also dependent assemblies. So in the catch() block, I tried to load them with FullName. And this worked and the documentation works like a charm now..!

http://www.codeproject.com/csharp/csharpcommentinganddocs.asp


Here is the full function I modified. The modified being in yellow color. File : NDoc2005\src\Documenter\Msdn\MsdnHtmlUtilitiesV20.cs for the method : InitializeNamespaces() /// /// Initialize namespace dictionary /// public static void InitializeNamespaces(Project project) { // If we don't have namespaces list yet, go through each referenced assembly, // load the assembly, get the types, then cache the namespaces for all public types. if (namespaces.Count == 0) { foreach (AssemblySlashDoc doc in project.AssemblySlashDocs) { // string strDllFullPath = doc.Assembly.Path; string strDllPath = strDllFullPath.Substring(0, strDllFullPath.LastIndexOf(@"\")+1); // Assembly theAssembly = Assembly.LoadFrom(doc.Assembly); AssemblyName[] assemblies = theAssembly.GetReferencedAssemblies(); foreach (AssemblyName an in assemblies) { //Assembly assembly = Assembly.LoadWithPartialName(an.Name); Assembly assembly = null; try { assembly = Assembly.LoadFrom(strDllPath + an.Name + ".dll"); } catch(Exception ex) { try { assembly = Assembly.Load(an.FullName); } catch (Exception ex1) { continue; } } if (assembly == null) { throw new System.IO.FileNotFoundException(String.Concat("Unable to locate the referenced Assembly ", an.Name)); } Type[] assemblyTypes = assembly.GetTypes(); foreach (Type type in assemblyTypes) { if (type.IsPublic) { namespaces[type.Namespace] = type.Namespace.Replace('.', '_') + '_'; namespaces[type.Namespace.Replace(".", "")] = ty-


pe.Namespace.Replace('.', '_') + '_'; } } } } } } I am not sure whether this is the bext fix for the problem I faced with NDoc, but this makes it working..!!

Documents

Master Thesis: Diplombericht Services-Framework für ein ...static.sws.bfh.ch/download/MAS-06-01-25-doc.pdf · Master Thesis: Diplombericht Services-Framework für ein Roboter Analyse