Entwicklung eines SCL-Codegenerators für die Entwicklungsumgebung TIA Portal · 2016-07-09 ·...

95
Entwicklung eines SCL-Codegenerators für die Entwicklungsumgebung TIA Portal Bachelorarbeit im Studiengang Informatik (dual) Fachbereich Elektrotechnik und Informatik Anna Elena Gillert In Progress, Stand: 8. Juli 2016 Erstprüfer: Prof. Dr. rer. nat. Nikolaus Wulff, FH Münster Zweitprüfer: Matthias Heinrich, Head of Process Control Software, GEA Group

Transcript of Entwicklung eines SCL-Codegenerators für die Entwicklungsumgebung TIA Portal · 2016-07-09 ·...

Entwicklung einesSCL-Codegenerators für die

Entwicklungsumgebung TIA Portal

Bachelorarbeit im Studiengang Informatik (dual)Fachbereich Elektrotechnik und Informatik

Anna Elena GillertIn Progress, Stand: 8. Juli 2016

Erstprüfer: Prof. Dr. rer. nat. Nikolaus Wulff, FH MünsterZweitprüfer: Matthias Heinrich, Head of Process Control Software, GEA Group

Inhaltsverzeichnis

Inhaltsverzeichnis

Inhaltsverzeichnis iii

1 Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Projektumfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Grundlagen 42.1 Separatoren und Dekanter . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Steuerungssoftware . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Siemens SIMATIC STEP 7 . . . . . . . . . . . . . . . . . . . 62.2.2 Siemens TIA Portal . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Microsoft Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.1 Visual Basic for Applications (VBA) . . . . . . . . . . . . . . 82.3.2 Office SDKs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Entwicklungstools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.1 Visual Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4.2 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.3 Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.4.4 JIRA und Confluence . . . . . . . . . . . . . . . . . . . . . . . 122.4.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 C # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.1 Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.2 Delegates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5.3 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Windows Presentation Foundation (WPF) . . . . . . . . . . . . . . . 162.6.1 XAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.6.2 Code-Behind . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6.3 Datenkontext und Datenbindung . . . . . . . . . . . . . . . . 182.6.4 Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.6.5 Model-View-ViewModel (MVVM) . . . . . . . . . . . . . . . . 21

3 Analyse und Planung 223.1 IST-Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1.1 Maschinenentwicklung . . . . . . . . . . . . . . . . . . . . . . 223.1.2 Softwareerstellung allgemein . . . . . . . . . . . . . . . . . . . 233.1.3 Softwareerstellung mit STEP 7 (bgen) . . . . . . . . . . . . . 253.1.4 Softwareerstellung mit TIA Portal . . . . . . . . . . . . . . . . 28

3.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

iii

Inhaltsverzeichnis

3.2.1 Systembezogene Anforderungen . . . . . . . . . . . . . . . . . 293.2.2 Fachliche Anforderungen . . . . . . . . . . . . . . . . . . . . . 30

4 Durchführung 354.1 Agile Softwareentwicklung . . . . . . . . . . . . . . . . . . . . . . . . 354.2 Projektaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.3 Logger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.4 Git-Updater . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.5 ModuleGenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.5.1 Laden der Moduldaten . . . . . . . . . . . . . . . . . . . . . . 414.5.2 Bereitstellung der Modulvorlagen . . . . . . . . . . . . . . . . 434.5.3 Abspeichern der Dateien . . . . . . . . . . . . . . . . . . . . . 444.5.4 Quellcodeerstellung . . . . . . . . . . . . . . . . . . . . . . . . 45

4.6 PlcImporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.7 GerTi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.7.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.7.2 ViewModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.7.3 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.7.4 Liste der generierten Dateien in der GUI . . . . . . . . . . . . 63

5 Tests 655.1 UnitTests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.1.1 Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675.1.2 ViewModels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.1.3 TIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.2 Manuelle Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

6 Schlussbemerkungen 726.1 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Abbildungsverzeichnis 76

Tabellenverzeichnis 77

Listings 78

Literatur 79

Glossar 81

Anhänge 83A Screenshots der Anwendung . . . . . . . . . . . . . . . . . . . . . . . 83

A.1 Hauptfenster beim Programmstart . . . . . . . . . . . . . . . 83

iv

Inhaltsverzeichnis

A.2 Hauptfenster bei geöffnetem Projekt . . . . . . . . . . . . . . 84A.3 Größenveränderung des Hauptfensters . . . . . . . . . . . . . 85A.4 Vergrößern der Loggingkonsole im Hauptfenster . . . . . . . . 86A.5 Konfigurationsfenster Tab 1 . . . . . . . . . . . . . . . . . . . 87A.6 Konfigurationsfenster Tab 2 . . . . . . . . . . . . . . . . . . . 87A.7 Konfigurationsfenster Tab 3 . . . . . . . . . . . . . . . . . . . 88

Erklärung 89

v

1 Einleitung

1.1 Motivation

Die GEA Group AG stellt am Standort Oelde große Industriezentrifugen her, dieeine komplexe Maschinensoftware zur Steuerung erfordern. Hardwareseitig kommendabei häufig speicherprogrammierbare Steuerungen von Siemens zum Einsatz, derenSoftware mit einer der Entwicklungsumgebungen Siemens SIMATIC STEP 7 oderSiemens TIA Portal erstellt werden kann. Gerade wenn nicht nur Einzelmaschinen,sondern vollständige Anlagen entwickelt werden, müssen hunderte Einzelkomponen-ten, wie zum Beispiel Sensoren und Aktoren, in der Software abgebildet werden, wasbei einer manuellen Programmierung einen sehr großen Aufwand und eine hohe Feh-leranfälligkeit mit sich zieht.

Aus diesem Grund wurde ein Visual Basic-Programm entwickelt, das mit der Ent-wicklungsumgebung STEP 7 kommuniziert und die Komponenten automatisiert aufBasis einer Excel-Liste anlegen kann. Es wird bisher ausschließlich in der Anlagenent-wicklung benutzt. STEP 7 wird am Standort Oelde der GEA bereits seit 16 Jahreneingesetzt, soll allerdings langfristig durch die Nachfolgerversion, das TIA Portal er-setzt werden, für das noch kein Tool existiert, mit dem die automatische Generierungder Komponenten möglich ist. Dieser Zustand hemmt die Verwendung des TIA Portalszur Softwareerstellung in der Anlagenentwicklung sehr stark.

Durch die Entwicklung einer neuen Software zur Quellcodegenerierung speziell für dasTIA Portal soll die Softwareerstellung mit dem TIA Portal beschleunigt werden unddie Ablösung von STEP 7 vorangetrieben werden. Dabei sollen auch Erfahrungen mitder alten Software – genannt bgen – miteinbezogen werden, damit ein erweiterbaresProgramm entsteht, das zukünftig auch weitere Entwicklungsumgebungen unterstüt-zen und auch im Bereich der Einzelmaschinen eingesetzt werden kann.

1.2 Projektumfeld

Im folgenden Abschnitt werden die GEA Group AG, der dazugehörige Standort Oel-de und die Abteilung Software Design, in der Maschinensoftware entwickelt wird,vorgestellt.

Die GEA Group AG ist ein weltweit agierender Hersteller von Prozesstechnik undKomponenten mit Sitz in Düsseldorf. Die Hauptgebiete des Unternehmens liegen imBereich der Nahrungsmittelverarbeitung. Mit diesem Bereich werden etwa 70% des

1

1 Einleitung

Umsatzes erwirtschaftet. Weitere Anwendungsgebiete sind die Geschäftsfelder Phar-mazie, Chemie, Marine, Energy, Oil & Gas oder auch der Freizeitbereich. Die GEAGroup beschäftigt global etwa 17 500 Mitarbeiter, von denen fast 2 000 am Standortin Oelde arbeiten.

Der Standort Oelde gehört legal zur GEA Westfalia Separator Group GmbH, einerTochtergesellschaft der GEA Group. GEA Westfalia Separator der weltweit führendeHersteller von Separatoren und Dekantern – großen Industriezentrifugen zur Trennungvon Flüssigkeiten und Fest-Flüssig-Gemischen. In Oelde werden primär Einzelsepa-ratoren gefertigt, die speziell auf Kundenwünsche angepasst sind und bei denen essich meist um Unikate handelt. Gleichzeitig befindet sich in Oelde ein Teil der Ver-waltung und Entwicklung der GEA Westfalia Separator. An weiteren Standorten inDeutschland, Frankreich, China und Indien werden Dekanter, standardisierte Separa-toren oder ganze Anlagen produziert.

Die Maschinensoftware für die Zentrifugen und Anlagen wird in der Abteilung Soft-ware Design erstellt, die sich am Standort Oelde befindet. Das Software Design istein Teil des Bereichs Automation and Controls, der sich wiederum in der AbteilungProduct Engineering and Development der GEA Group wiederfindet. Es kommen fürdie Maschienen verschiedene Steuerungen zum Einsatz, von denen Siemens fast dreiViertel und der Hersteller Rockwell weitere 20% stellt. Auch das Design und die Um-setzung der grafischen Oberflächen für die Steuerungen und der Support von Kundengehören zum Aufgabengebiet des Software Designs.

Das in dieser Arbeit beschriebene Vorgehen bezieht sich stets auf den GEA-StandortOelde. Zur Vereinfachung wird als Name GEA und nicht GEA Westfalia Separatorgewählt.

1.3 Aufgabenstellung

Ziel dieses Projektes ist es, eine neue Software zu entwickeln, die auf Basis einer Excel-Liste Quellcode für das TIA Portal generieren kann. Als Programmiersprache wirddazu C# herangezogen. Es soll eine grafische Oberfläche mit dem Grafik-FrameworkWindows Presentation Foundation (WPF) entwickelt werden, welche den AnwendernZugriff auf die Funktionen des Programms bietet.

Die Verwendung von mehreren neuen Technologien ist von Anfang an Teil des Pro-jektes. Es sollen erste neue Erfahrungen mit den Entwicklungstools Jenkins, JIRAund Confluence und mit den Frameworks ClosedXML, TIA Openness und WPF ge-wonnen werden. Der Fokus dieser Arbeit liegt allerdings nicht auf einer Bewertungdieser Technologien. Zudem soll nach dem Softwareentwicklungsmodell Scrum gear-beitet werden. Es handelt sich dabei um ein inkrementelles Modell, das den ProductOwner, also den Auftraggeber, stark in den Entwicklungsprozess mit einbezieht.

2

1.4 Gliederung der Arbeit

Vorlagendateien auf ASCII-Text-Basis sollen als Grundlage für den zu generieren-den Quellcode im TIA Portal dienen. Da für aktuelle TIA-Projekte vornehmlich dieMaschinen-Programmiersprache SCL eingesetzt wird, soll sich in den Vorlagen un-vollständiger SCL-Quellcode befinden, der durch die neue Software mit den Datenaus der Excel-Liste ergänzt werden soll. Die Erstellung der Vorlagendateien selbst istnicht Bestandteil dieser Arbeit.

1.4 Gliederung der Arbeit

In Kapitel 2 werden zunächst die erforderlichen Grundlagen vermittelt, die für dieArbeit mit den oben genannten Tools und Frameworks und schließlich zur Entwicklungder Software benötigt werden. Konkret werden die Produkte des Unternehmens unddie darin eingebauten Steuerungen aufgezeigt, bevor einige Anwendungsprogrammeund Entwicklungstools und schließlich die Windows Presentation Foundation erläutertwerden.

Danach wird in Kapitel 3 mit der Analyse und Planung des Projektes fortgeschritten.In diesem Zuge werden die fachlichen und systembezogenen Anforderungen an dieSoftware ermittelt und im Rahmen des IST-Zustandes wird die Software-Entwicklungmit den Tools Siemens STEP 7 beziehungsweise TIA Portal beleuchtet. Die Durch-führung des Projektes mit den neu entwickelten Strukturen und Lösungen wird inKapitel 4 beschrieben und in Kapitel 5 werden die durchgeführten UnitTests und diemanuell durchgeführten Tests behandelt.

Kapitel 6 stellt den Schlussteil dar und zieht ein Fazit über die entwickelte Software.Anschließend wird noch ein Ausblick in die Zukunft gegeben.

Da die Software nach dem Vorgehensmodell Scrum entwickelt wurde, stimmt die zeit-liche Reihenfolge der Darstellung in dieser Arbeit nicht zwangläufig mit der tatsäch-lichen Ausführung überein. So wurden beispielsweise die Anforderungen im Projekt-verlauf angepasst und die Durchführung und die Tests wurden parallel – und nichtetwa hintereinander – bearbeitet.

Dargestellte Quellcodebeispiele sind im Allgemeinen gekürzt. Dabei wurden häufigKommentare oder Lognachrichten entfernt oder Variablennamen gekürzt, um denCode auf das Wesentliche zu beschränken und die Beispiele kurz zu halten.

3

2 Grundlagen

2 GrundlagenIn diesem Kapitel werden für die vorliegende Arbeit relevante Grundlagen vorgestellt,die für das weitere Verständnis der Arbeit nötig sind. Dabei handelt es sich sowohlum verwendete Maschinen und Steuerungen als auch um Anwendungsprogramme undTools für Entwickler.

2.1 Separatoren und Dekanter

Am GEA-Standort Oelde werden schon seit über 120 Jahren Industriezentrifugenhergestellt. Sowohl Separatoren als auch Dekanter nutzen die Zentrifugalkraft, umFlüssigkeiten und Flüssigkeitsgemische mit unterschiedlichen Dichten voneinander zutrennen. Bei dieser mechanischen Trennung können Durchlaufleistungen von bis zu500 000 l/h erreicht werden. Abbildung 1 stellt einen Separator dar, Abbildung 2 einenDekanter.

Abb. 1: Separator, Quelle: [10] Abb. 2: Dekanter, Quelle: [9]

Separatoren werden eingesetzt, wenn Medien mit einem Feststoffanteil von bis zu7% getrennt werden sollen. Sie können Feststoffpartikel ab einer Größe von 0, 5µmvon einer Flüssigkeit abtrennen. Sogenannte 2-Phasen-Separatoren können zusätzlichnoch zwei Flüssigkeiten voneinander trennen, was beispielsweise für Wasser-Öl-Sand-Gemische verwendet wird. Im Separator befindet sich eine Trommel, durch die dasProdukt geleitet wird. Die Trommel rotiert bei größeren Separatoren mit bis zu 4 500Umdrehungen pro Minute, bei kleineren Separatoren sogar mit bis zu 15 000 Umdre-hungen. Substanzen mit höherer Dichte setzen sich am Rand der Trommel ab undwerden von dort aus nach außen abgeschleudert.

4

2.2 Steuerungssoftware

Dekanter können auch mit deutlich höheren Feststoffanteilen umgehen, dafür abererst Teilchen ab einer Größe von 5µm aus Flüssigkeiten abtrennen. Eine Schnecke imInneren des Dekanters transportiert die anfallenden Feststoffe laufend ab.

Separatoren und Dekanter werden in fast allen Industriebereichen zur Flüssigkeitstren-nung eingesetzt. Der Separator auf Abbildung 1 wird zum Beispiel in der Getränke-technik eingesetzt, der Dekanter auf Abbildung 2 im Bereich der Abwasserklärung.Typische Anwendungsfelder für Separatoren sind die Klärung von Fruchtsäften oderBier, die Milchtrennung und -Verarbeitung, aber auch Pharmazie- oder Marineanwen-dungen, wie die Herstellung von Tabletten oder Impfstoffen und die Säuberung von aufSchiffen verwendetem Schweröl. Mit Dekantern können zum Beispiel Olivenöl, Weinoder Sojamilch hergestellt werden, zusätzlich können sie auch in Kläranlagen oderin der Tierkadaververarbeitung eingesetzt werden. An den Maschinen sind zahlreicheVentile, Motoren und Sensoren verbaut, die über eine komplexe Software gesteuertwerden.

2.2 Steuerungssoftware

Eine speicherprogrammierbare Steuerung (SPS, engl.: Programmable Logic Control-ler, PLC) ist ein elektronisches Gerät, mit dem komplexe Maschinen – insbesonderedaran angeschlossene Sensoren und Aktoren – gesteuert werden können. Wie der Na-me suggeriert, besitzt eine SPS einen Speicher und kann programmiert werden; dieSteuerungsabläufe liegen also nicht mehr fest verdrahtet in Hardware vor.

Zur Maschinensteuerung werden bei GEA häufig speicherprogrammierbare Steuerun-gen von Siemens eingesetzt. Unter dem Produktnamen SIMATIC vertreibt Siemenssogenannte S7-Steuerungen, die in verschiedenen Serien vorhanden sind. Die S7-300erund S7-400er Serien sind seit rund 20 Jahren auf dem Markt, werden allerdings immernoch verkauft und auch aktuell von GEA eingesetzt. Langfristig sollen sie von den S7-1200er und S7-1500er Serien abgelöst werden, wobei die 1200er Serie für das niedrigereLeistungssegment und die 1500er Serie zur Steuerung größerer Anlagen konzipiert ist(vgl. [11]). Auch diese Serien werden aktuell schon bei GEA verwendet.

Zusätzlich zur SPS wird zur Steuerung der Maschine ein Bedienpanel für den Benut-zer benötigt, das als Schnittstelle Steuerungsbefehle entgegennimmt und den aktuellenStatus der Maschine anzeigt. Das Bedienpanel wird meist Human-Machine-Interface(HMI) genannt. Hierbei handelt es sich oft um einen kleinen Computer, auf dem einvollständiges Betriebssystem (zum Beispiel Microsoft Windows CE) installiert ist, eskommen aber auch herkömmliche PCs zum Einsatz, auf denen dann eine Zusatzsoft-ware die Benutzerschnittstelle bildet. Zwischen HMI und SPS werden Daten ausge-tauscht, damit die Zustände der SPS korrekt dargestellt werden und Steuerungsdatenvom HMI an die SPS gesendet werden können.

5

2 Grundlagen

2.2.1 Siemens SIMATIC STEP 7

SIMATIC STEP 7 ist eine integrierte Entwicklungsumgebung zur Programmierungvon speicherprogrammierbaren Steuerungen und wurde von Siemens im Jahr 1995 inder Version 1.0 herausgebracht. Die S7-300er und S7-400er Steuerungen können mitSTEP 7 programmiert werden.

Ab der Version 10.5, die 2009 erschienen ist, ist STEP 7 in das TIA Portal (siehe nach-folgender Abschnitt) integriert, bei GEA wird Version 5.5 allerdings noch produktiveingesetzt, da einige Features dieser Version nicht im TIA Portal enthalten sind. Indieser Arbeit ist – wenn nicht anders angegeben – mit STEP 7 stets die Version 5.5im Service Pack 4 gemeint.

Für die Programmierung der Controller werden sowohl grafische Programmierspra-chen (beispielsweise KOP und FUP1) als auch textuelle Sprachen wie AWL2 oderSCL3 unterstützt. Dabei sind KOP, FUP und AWL in STEP 7 nativ vorhanden, SCLwird durch eine spezielle Erweiterung unterstützt (vgl. [12]). SCL wird bei GEA vorallem in neueren Steuerungen verwendet, in älteren Modellen kommen eher AWL odereine der grafischen Programmiersprachen zum Einsatz.

Siemens gibt zudem eine Schnittstelle vor, die SIMATIC 1.0 Type Library, die dieDatenübertragung in ein STEP 7 Projekt aus einer Excel-Tabelle heraus mithilfeder Programmiersprache Visual Basic for Applications ermöglicht. Diese Schnittstelleentfällt mit neueren Versionen von STEP 7.

2.2.2 Siemens TIA Portal

Das TIA Portal ist eine integrierte Entwicklungsumgebung, in der mehrere verschiede-ne Programme zusammengefasst sind. So ist zum einen eine neue Version von STEP 7enthalten (Version 13), die nativ SCL unterstützt, zum anderen ist ein Programm na-mens WinCC Advanced integriert, das zum Erstellen von grafischen Oberflächen fürHMIs und PCs dient. Weitere Software kann zusätzlich installiert werden und ist dannauch innerhalb des TIA Portals verfügbar. Dazu gehört zum Beispiel eine Simulati-onssoftware, mit der die Programme und Oberflächen getestet werden können. Mitder Entwicklung des TIA Portals wurde von Siemens eine Vereinfachung von Auto-matisierungsprozessen und eine Beschleunigung der Entwicklung von Software durchVerwendung einer einzelnen „Engineeringumgebung“ [13] angestrebt. GEA setzt dasTIA Portal aktuell in Version 13 ein.

1Kontaktplan bzw. Funktionsplan2Anweisungsliste, eine eher assembler-ähnliche Sprache.3Structured Control Language, eine Hochsprache zur Programmierung von SPS, die von der Syntaxher Pascal ähnelt.

6

2.2 Steuerungssoftware

Die neueren Controller, die von Siemens angeboten werden (insbesondere die S7-1200er und S7-1500er Serien), können ausschließlich mit dem TIA Portal, nicht mehrmit STEP 7, programmiert werden. Eine Übersicht zu den vorhandenen Steuerungenund möglichen IDEs ist in Abbildung 3 dargestellt.

S7-300er oderS7-400er Serie

1200er oder1500er Serie

SPS

SIMATICSTEP 7

TIA Portal

IDE

Abb. 3: Verwendung von Tools und Programmen bei der SW-Erstellung

TIA Portal Openness

Mit TIA Portal Openness stellt Siemens eine öffentliche API bereit, die es ermögli-chen soll, Prozesse im TIA Portal zu automatisieren. TIA Portal Openness wird mitaktuellen Versionen von WinCC bzw. STEP 7 ausgeliefert und basiert auf dem .NETFramework 4.0 (vgl. [14, S. 4,11]). In einem dedizierten PDF stellt Siemens die APIanhand einer Einführung und Demoanwendung in C# vor (siehe [14]), die vollstän-dige Dokumentation findet sich in der „TIA-Online-Hilfe“, also dem im TIA Portalenthaltenen Hilfsprogramm.

Zur Verwendung von Openness in einem Entwicklungsprojekt muss eine von Siemenserstellte DLL4 in das Projekt miteinbezogen werden. Zusätzlich muss auf jedem PC,der die Software verwendet, eine Installation von Openness durchgeführt werden.

Durch Openness können unter anderem folgende Funktionen automatisiert werden:

• Öffnen und Schließen des TIA Portals

• Öffnen, Schließen und Speichern eines Projektes im TIA Portal

• HMI-Elemente als XML exportieren und importieren4Eine DLL (Dynamic Link Library) ist unter Microsoft-Betriebssystemen eine Programmbibliothek.

7

2 Grundlagen

• Übersetzung von Hardware und Software anstoßen

• Bausteine als XML exportieren und importieren (mit bestimmten Einschrän-kungen)

Insbesondere der Import von Bausteinen ist für diese Arbeit relevant.

2.3 Microsoft Excel

Microsoft Excel ist ein von Microsoft entwickeltes Tabellenkalkulationsprogramm, daseinen Hauptbestandteil der Microsoft Office Programmsuite bildet und in vielen Fir-men als ein etabliertes Tool zur Auswertung von Daten Verwendung findet. Die ersteVersion von Excel wurde 1985 veröffentlicht, seitdem folgten eine Vielzahl weitererVersionen, insbesondere Excel 2003, 2007, 2010, 2013 und seit diesem Jahr auch Ex-cel 2016.

Im Folgenden werden einige der für diese Arbeit relevanten, von Excel verwendetenBegriffe kurz erläutert.

Ein Excel-Dokument besteht aus Tabellenblättern, deren Inhalt eine Matrix von Zel-len ist, die über Angabe ihrer Zeilennummer (als Integer) und ihrer Spaltennummer(als Buchstabe, von A-Z, dann AA-ZZ) identifiziert werden können (zum Beispiel C15).Tabellenblätter haben einen eindeutigen Namen und werden von Excel in einer Re-gisterleiste im unteren Bereich des Hauptfensters aufgelistet. Im Dokument muss esmindestens ein Tabellenblatt geben.

Jede Zelle kann als Inhalt einen Wert (value) besitzen, bei dem es sich zum Beispielum eine Zahl, einen String oder um ein Datum handeln kann. Es besteht auch dieMöglichkeit, anstelle des Wertes eine Formel anzugeben, mit der der Wert berechnetwerden kann. Wenn andere Zellen in die Berechnung miteinbezogen werden sollen, sokönnen sie über Angabe der Zellennummer und falls nötig auch des Namens des Ta-bellenblatts referenziert werden. Bekannte Formeln sind zum Beispiel WENN, SVERWEISoder SUMME.

Ein Bereich ist eine Menge von zusammenhängenden Zellen, der über Angabe derZelle oben links und der Zelle unten rechts angegeben werden kann. Die Zellen A2 bisC5 können mit A2:C5 angesprochen werden.

2.3.1 Visual Basic for Applications (VBA)

Visual Basic for Applications (VBA) ist eine interpretierte Programmiersprache zurBenutzung in Microsoft Office Anwendungen, die von Entwicklern genutzt wird, umin Officedokumenten bestimmte Abläufe automatisiert abzuarbeiten. Sie erweitert die

8

2.3 Microsoft Excel

bereits vorhandenen Formeln um frei programmierbare Funktionen, die unabhängigvon den Daten des Excel-Dokuments arbeiten können, aber auch auf einzelne Zellenund Zellbereiche zugreifen können.

In der Abteilung Software Design wird VBA primär zur Datenaufbereitung innerhalbvon Excel-Dokumenten verwendet. Eine Ausnahme bildet das Programm bgen, dasvollständig in Visual Basic for Applications geschrieben ist. Dieses Programm ist fürdie vorliegende Arbeit von Bedeutung und seine Aufgabe wird daher in Abschnitt 3.1.3weitergehend beleuchtet.

2.3.2 Office SDKs

Microsoft Office Anwendungen ab Office 2007 verwenden zur Speicherung der Office-dokumente ein speziell von Microsoft entwickeltes und standardisiertes Dateiformatauf XML-Basis, dasMicrosoft Office Open XML-Format (OOXML). Das Format wur-de 2006 von der ECMA International als ECMA-376 [6] standardisiert. Es existiertauch eine weitere, ähnliche Version, die ISO-genormt ist: ISO/IEC 29500 [15]. Einsder Ziele dieses Formats ist es, auch anderen Anwendungen, zum Beispiel Fremd- oderUnternehmensanwendungen, mithilfe von XML Zugriff auf Office-Dokumente zu er-möglichen. Die Microsoft-Dokumentation zum Office Open XML-Format kann unter[4] eingesehen werden.

OpenXML SDK

Mit dem Open XML SDK (aktuell in Version 2.5) stellt Microsoft ein Software De-velopment Kit mit verschiedenen Bibliotheken bereit, die Open XML-Dokumenteanlegen, bearbeiten und auslesen können. Der Quellcode des SDKs ist auf GitHubverfügbar (siehe [16]), zu großen Teilen unter der Apache 2.0 License lizenziert, undhauptsächlich in C# geschrieben. Zum Zugriff auf die XML-Daten verwendet er dasVerfahren LINQ (Language Integrated Query), das ebenfalls von Microsoft entwickeltwird. Zur Verwendung des SDKs wird keine Installation von Microsoft Office Produk-ten vorausgesetzt, es kann sowohl unter Windows als auch unter Linux5 oder MacOS X eingesetzt werden.

Die Manipulation der Dokumente mithilfe des SDKs geschieht auf einer XML-nahenEbene, sodass es zusätzlich zum Open XML SDK Erweiterungen gibt, die den Zugriffspeziell für Excel-Dateien vereinfachen.

5Bei Verwendung von Linux kann das Mono-Projekt verwendet werden, das eine quelloffene Imple-mentierung des .NET Frameworks bereitstellt.

9

2 Grundlagen

ClosedXML

ClosedXML ist eine Programmbibliothek, die anstrebt, die Handhabung von Excel-Dateien für Entwickler im Vergleich zum Open XML SDK zu vereinfachen, indem sieeinen Wrapper um die Open XML Klassen bildet. Das Projekt steht unter der MITLicense, wird aber nicht direkt von Microsoft entwickelt und ist auf der PlattformCodePlex verfügbar: [8].

Der Zugriff auf Tabellenblätter und Zellen geschieht bei ClosedXML im VBA-Stil.Folgender Codeausschnitt zeigt die Verwendung von ClosedXML zur Erstellung einerneuen Datei mit einem Text-Inhalt in Zelle A1:

1 var workbook = new XLWorkbook ();2 var worksheet = workbook.Worksheets.Add("Tabelle Hello");3 worksheet.Cell("A1").Value = "Hello World!";4 workbook.SaveAs("HelloWorld.xlsx");

Listing 1: Hello World Beispiel mit ClosedXML

ClosedXML unterstützt außerdem die Auswertung von Excel-Formeln.

2.4 Entwicklungstools

Im folgenden Unterkapitel werden bei der Implementierung verwendete Entwicklungs-programme vorgestellt. Dazu gehören Tools zur Quellcode-Erstellung und -Verwaltungund Produkte des Unternehmens Atlassian Corporation zur Dokumentation und zumProjektmanagement.

2.4.1 Visual Studio

Zur Programmierung von Anwendungen in der Programmiersprache C# wird beiGEA die von Microsoft entwickelte integrierte Entwicklungsumgebung Visual Stu-dio 2015 Professional verwendet. Visual Studio zeichnet sich dadurch aus, dass esverschiedene Editoren integriert – nicht nur für Quelltext, sondern auch für Klassen-diagramme, grafische Oberflächen oder Datenbankschemata. Im Klassendiagramm-Editor kann aus den angezeigten Klassen Quellcode generiert werden. Auch der um-gekehrte Weg, das Anzeigen bestehender Klassen als Diagramm, ist möglich, wodurchnicht nur die Erstellung, sondern auch die Pflege von bestehenden Diagrammen er-heblich vereinfacht wird. Der Editor für grafische Oberflächen erlaubt es, Oberflächen,

10

2.4 Entwicklungstools

die mit einem der Grafikframeworks WPF oder Windows Forms erstellt wurden, par-allel zu ihrem Quellcode direkt anzuzeigen und auch über den grafischen Editor zumodifizieren. Zudem kann für UnitTests auf das integrierte UnitTesting Frameworkzurückgegriffen werden.

In Visual Studio werden einzelne Entwicklungsprojekte als Solution bezeichnet, darinenthaltene Untergruppen als Projects. Diese Untergruppen werden in der Program-miersprache Java auch als Packages bezeichnet.

Bei GEA wird zusätzlich das Plugin ReSharper verwendet, das die Einhaltung vonStandards zur Variablenbennenung überwacht, erweiterte Refactoring-Optionen bietetund Tipps zur Verbesserung des Quellcodes liefert. Es kann auch UnitTests ausführenund die Quellcodeabdeckung der Tests ermitteln.

Mit Visual Studio werden vornehmlich Anwendungen für das .NET-Framework ge-schrieben, einer Software-Plattform von Microsoft, die für Entwickler verschiedeneLibraries bereitstellt und in der fertiggestellte Anwendungen ausgeführt werden kön-nen. Es werden mehrere Programmiersprachen, unter anderem Visual C# und VisualBasic, unterstützt.

2.4.2 Git

Um den entstandenen Source-Code (und auch dieses Dokument) zu versionieren, wirddas Tool Git verwendet. Git ist ein frei verfügbares Versionsverwaltungssystem, dasseit der Entstehung im Jahr 2005 kontinuierlich weiterentwickelt wird.

Im Gegensatz zu Systemen, die die Dateien auf einen zentralen Server laden, hatGit eine verteilte Struktur: In jeder Kopie des Repositories sind stets alle Dateienenthalten.

Bei GEA werden die Git bash für die Steuerung per Shell und Tortoise Git als gra-fisches Tool auf PC-Arbeitsplätzen eingesetzt. Als remote-Repository dient ein Git-Server auf dem die Software gitblit installiert ist, die zusätzlich eine grafische Webo-berfläche und einen Backup-Service für das Repository bereitstellt.

2.4.3 Jenkins

Jenkins ist ein quelloffener Automationsserver, der das Kompilieren, Testen und Be-reitstellen von verschiedenen Arten von Projekten ermöglicht.

Es werden zahlreiche Plugins für Zusatzfunktionalitäten angeboten, wie zum Beispielein Git Plugin, das Jenkins dazu befähigt, Source-Code aus einem Git Repositoryherunterzuladen und automatisch bei jeder Änderung im Repository den Code zu

11

2 Grundlagen

bauen und zu testen. Andere Plugins unterstützen zum Beispiel Unit Testing Fra-meworks, die Ermittlung der Testabdeckung oder automatische Valgrind-Tests6 derAnwendung. Für Jenkins existiert eine Weboberfläche, die das Einsehen der Projektevereinfacht.

Bei GEA am Standort Bönen trägt Jenkins bereits dazu bei, durch kontinuierlichesBauen und Testen der Entwicklungsprojekte eine hohe Codequalität sicherzustellen.Dazu holt Jenkins den aktuellen Codestand vom gitblit-Server ab, sobald dort eineneue Version erscheint.

2.4.4 JIRA und Confluence

JIRA ist eine vom Softwareunternehmen Atlassian entwickelte, webbasierte Projekt-managementanwendung, die hauptsächlich im Bereich der agilen Softwareentwicklungeingesetzt wird.

Mit JIRA kann ein Projekt mithilfe des Vorgehensmodells Scrum verwaltet werden.Es werden der Aufbau eines Backlogs mit Arbeitsaufgaben (Issues), die Erstellungund die Abarbeitung von Sprints, Burndown-Charts und eine Versionskontrolle un-terstützt.

Ein weiteres webbasiertes Produkt von Atlassian ist Confluence. Es unterstützt dieErstellung von Wikis und Softwaredokumentationen mithilfe eines einfachen WYSI-WYG7-Editors, der leicht zu bedienen ist. Einzelne Wiki-Seiten können beobachtetwerden und Nutzer können über Änderungen an Seiten informiert werden. Die Do-kumentation der in dieser Arbeit vorgestellten Software wird mithilfe von Confluenceerstellt.

2.4.5 Zusammenfassung

Die bei diesem Projekt bestehende Infrastruktur wird in Abbildung 4 zusammen-gefasst. Programmcode wird mithilfe von Visual Studio entwickelt, im Git „einge-checkt“ und schließlich mit dem Befehl git push auf den gitblit-Server übertragen. DerJenkins-Server holt sich den aktuellen Code-Stand bei Änderungen automatisch ausdem gitblit ab und baut und testet das Projekt. Die Dokumentation des Programm-codes und die Organisation des Projektes wird von den Tools JIRA und Confluenceunterstützt.

6Valgrind ist ein freies Tool zum Auffinden von Speicherfehlern in C/C++ basierten Programmen.7What you see is what you get.

12

2.5 C #

gitblit Jenkins

Git

Git

Developer

Developer

Confluence

JIRA

git push/pull

git push/pull

VS

VS

Abb. 4: Projektinfrastruktur bei den verwendeten Entwicklungstools

2.5 C #

Zusammen mit der Einführung von .NET hat Microsoft im Jahr 2000 auch eine neueAllzweck-Programmiersprache herausgebracht. Während die Sprachdefinition von C#selbst ISO- und Ecma-zertifiziert ist, hat Microsoft eine eigene Implementierung ent-wickelt, die „Visual C#“ genannt wird. Mit Mono existiert auch eine quelloffene Im-plementierung, die auf Linux eingesetzt werden kann.

C# weist von der Syntax und vom Funktionsumfang einige Ähnlichkeiten zu Java oderC++ auf: Die Sprache ist objektorientiert, unterstützt implizit typisierte Variablende-klarationen, Properties, Delegaten und ist Event-orientiert. Kompilierte Programmewerden in eine Zwischensprache übersetzt und von einer Laufzeitumgebung ausge-führt, die zum Beispiel auch die Garbage Collection im Programm übernimmt. DerZugriff auf Klassenvariablen kann durch einen der vier Zugriffsmodifizierer public,protected, internal oder private beschränkt werden. Mit dem Schlüsselwort partialclass kann eine Klasse erstellt werden, die auf mehrere Dateien aufgeteilt ist, sodassin jeder der Dateien ein Teil der Klasse zu finden ist. Auch generische Typen sind inder aktuellen Version von C# vorhanden. Interfaces werden unterstützt und meistensdurch ein vorgestelltes „I“ im Namen gekennzeichnet.

Drei der oben erwähnten Funktionen von C# werden im folgenden Abschnitt nähererklärt, da sie für diese Arbeit besonders relevant sind: Properties, Delegates undEvents.

2.5.1 Properties

In C# können sogenannte Properties verwendet werden. Dabei handelt es sich um eineKombination aus einem Feld einer Klasse und zwei Methoden: einem set-Accessor

13

2 Grundlagen

und einem get-Accessor, die Programmlogik zum Setzen und Abfragen des Feldesbeinhalten. Wird im Code auf den Inhalt des Feldes (entweder lesend oder schreibend)zugegriffen, so werden automatisch die get- und set-Methoden aufgerufen. Zusätzlichzum Property wird häufig eine weitere, private Variable mit dem gleichen Datentypwie das Property angelegt, die den Wert des Properties speichert und die BezeichnungBacking Store oder Backing Variable trägt. Listing 2 zeigt ein Beispiel zur Verwendungeines Properties mit einem zusätzlichen Plausibilitätscheck im set-Accessor.

1 public class FileManager {2 // Backing variable3 private string filename;4

5 // Property6 public string Filename {7 get { return filename; }8 set { if (System.IO.File.Exists(value) { filename = value;

}}9 }

10 }

Listing 2: Beispiel zu Properties in C#

Laut Namenskonvention wird bei GEA die private Backing Variable klein und daszugehörige Property groß geschrieben.

Properties werden verwendet, da sie beim Setzen oder Auslesen einer Variablen Zu-satzfunktionalitäten auslösen können. So kann der Wert des Properties (anstelle eineBacking Variable zu verwenden) aus einer anderen Datenquelle wie zum Beispiel einerXML-Datei extrahiert werden, oder andere Instanzen können über die Änderung amWert informiert werden. Durch dieses Feature wird das Erstellen von den aus Javabekannten Getter- und Setter-Methoden vermieden und der Quellcode übersichtlichergemacht.

2.5.2 Delegates

An das Konzept der aus C oder C++ bekannten Funktionszeiger angelehnt, bietenDelegates eine typsichere Möglichkeit, um Verweise auf Methoden einer Klasse zu set-zen. Bei der Deklaration des Delegates mit dem Schlüsselwort delegate wird sowohlder Rückgabetyp als auch die Parameter der Methode festgelegt, auf die der Dele-gate verweisen kann. Versucht man, dem Delegaten eine Methode zuzuweisen, derenSignatur nicht zum Typ des Delegaten passt, wird dies direkt durch den Compilerabgefangen. Dadurch werden falsche Zuweisungen, die das Programm zum Absturz

14

2.5 C #

bringen würden, schon bei der Programmierung vermieden. Die Deklaration des De-legates kann sowohl außerhalb einer Klasse als auch innerhalb geschehen.

Listing 3 zeigt die Anlage und Verwendung eines Delegaten in C#. Es muss un-terschieden werden zwischen der Deklaration eines Delegat-Typs (Zeile 1), die denRückgabewert und die Parameter festlegt, der Instanz eines Delegaten (eines Objek-tes vom Typ des Delegaten, Zeile 4) und der Methode, die dem Delegaten zugewiesenwird (Zeile 8).

1 delegate int doSomething(object e);2

3 void example () {4 doSomething d1;5 d1 = new doSomething(myMethod);6 }7

8 int myMethod(object e) {9 // ...

10 }

Listing 3: Beispiel zur Deklaration eines Delegates in C#

Delegates können verknüpft werden, sodass mehrere Methoden hintereinander ausge-führt werden. Dazu kann der Operator += verwendet werden, sodass mit d1 += d2; derDelegate d2 zum Delegate d1 hinzugefügt wird. Analog kann aus einem zusammenge-setzten Delegaten der Delegate d2 mit d1 -= d2; entfernt werden.

Einige Delegates sind bereits von Microsoft vordefiniert, zum Beispiel delegate voidSystem.Action() oder delegate bool System.Predicate<in T>(T obj).

2.5.3 Events

Events in C# bauen auf dem Konzept der Delegates auf, erweitern dies aber noch.Die Deklaration sieht wie folgt aus:

1 // General syntax2 <Access_modifier > event <Delegate_type > <Name >;3

4 // Example5 public event Action NameChangedEvent;

Listing 4: Deklaration eines Events in C#

15

2 Grundlagen

Events bieten eine Funktionalität, die dem Observer-Pattern ähnelt. Ein zu beob-achtendes Objekt (das Observable) kann ein Event feuern, über das dann alle inter-essierten Objekte (die Observer) informiert werden. Dazu muss das Observable einEvent deklarieren und die Observer müssen eine Methode passend zum Event-Typimplementieren und diese an das Event im Observable anhängen.

Mit einem Delegaten könnte man bereits große Teile dieses Patterns umsetzen. EinObservable könnte ein public delegate deklarieren und Observer könnten mithilfe vonobservable.del += myDelegate; eine Methode an den Delegaten anhängen. Dann kanndas Observable wenn nötig den Delegaten aufrufen, um Observer zu informieren.Diese Implementierung würde aber dazu führen, dass ein Observer mit observable.del = myDelegate alle anderen Delegates des Observables entfernen würde – nur nochein einziger Observer würde vom Observable über Änderungen informiert. Um dieszu verhindern, müssten zusätzliche Methoden geschrieben werden, die das sichereHinzufügen und Entfernen eines Event Handlers ermöglichen.

Genau diese Extrafunktionalität liefern Events. Ein Event hat stets die Methoden addund remove, die Observer mithilfe der Kurzschreibweise myEvent += myDelegate bezie-hungsweise myEvent -= myDelegate aufrufen können. In der Deklaration im Listing 4werden bereits implizit die beiden Methoden angelegt, eine explizite Deklaration istauch möglich und erlaubt es, die Methoden zu modifizieren. Diese Methode wird hierallerdings nicht weiter behandelt.

Events werden zum Beispiel von grafischen Oberflächen – insbesondere von der Win-dows Presentation Foundation, die in Abschnitt 2.6 beschrieben ist – benutzt, umButtonklicks und Variablenänderungen an andere Objekte weiterzugeben.

2.6 Windows Presentation Foundation (WPF)

Die Windows Presentation Foundation (WPF) ist ein von Microsoft entwickeltes Fra-mework zur Erstellung von grafischen Benutzeroberflächen (GUIs), das seit 2006 ver-fügbar ist und im .NET-Framework enthalten ist. Es ist als Nachfolger des Frame-works Windows Forms konzipiert worden und soll die Trennung von Programmlogikund grafischer Oberfläche im Vergleich zu Windows Forms erleichtern.

Mit Visual Studio 2015 können standardmäßig WPF-Anwendungen entwickelt wer-den. Im Benutzerdialog zur Anlage einer neuen Solution können direkt WPF-An-wendungen ausgewählt werden, dabei wird ein erstes Fenster, das MainWindow, undeinige Konfigurationsdateien angelegt, sowie benötigte Referenzen zum Projekt hin-zugefügt.

Für die Platzierung der grafischen Elemente auf der Oberfläche und die Verknüpfungmit Funktionen des Programms stellt Microsoft eine Auszeichnungssprache bereit, die

16

2.6 Windows Presentation Foundation (WPF)

auf XML basiert, sodass keine Programmierkenntnisse für das Oberflächendesign be-nötigt werden. In den nächsten Abschnitten werden diese Auszeichnungssprache undandere für diese Arbeit relevanten Features und Grundlagen der Windows Presen-tation Foundation erläutert, darunter Code-Behind-Dateien, Datenbindung und dasEntwurfsmuster Model-View-ViewModel.

2.6.1 XAML

Ein wichtiges Feature von WPF ist die Beschreibung der anzuzeigenden Fenster undgrafischen Elemente mithilfe eines XML-Dialekts, der eXtensible Application MarkupLanguage, kurz XAML. Meist existiert pro vorhandenem Fenster eine .xaml-Datei, dieden grafischen Aufbau des Fensters beschreibt und eine Code-Behind-Datei, in der ineiner .NET-Sprache wie C# oder Visual Basic zusätzliche Programmlogik implemen-tiert werden kann.

Im Visual Studio ist eine WYSIWYG8-Design-Ansicht integriert, mit der das Layouteines in XAML definierten Fensters angezeigt und modifiziert werden kann.

Einzelne Elemente des Fensters, wie zum Beispiel Buttons, Bilder, CheckBoxen oderLabels werden als XML-Elemente mithilfe von Tags definiert, die in spitzen Klammernstehen. Dabei kann es entweder zwei Tags geben (einen öffnenden und einen schlie-ßenden), oder eine Kombination aus den beiden in einem einzelnen Tag. Listing 5zeigt die zwei Möglichkeiten beispielhaft anhand des Elements Button.

1 <!-- Opening and closing tag -->2 <Button >OK </Button >3

4 <!-- Combined tag -->5 <Button Content="OK"/>

Listing 5: Beispiel zu Tags in XAML

Elemente können Eigenschaften, sogenannte Attribute haben, die das Element genauerdefinieren. Beim Button kann dies der Inhalt bzw. der Text auf dem Button sein, aberauch Größenangaben oder EventHandler können über Attribute angegeben werden.Attribute werden innerhalb der spitzen Klammern eines öffnenden Tags definiert, ihrInhalt wird unabhängig vom Datentyp des Attributs als Text in doppelten Anfüh-rungsstrichen geschrieben. Beim Parsen des XAML-Codes werden dann die nötigenTypkonvertierungen durchgeführt. Ein Sonderfall unter den Attributen ist Content.Der Inhalt dieses Wertes kann wahlweise als Attribut mit Content="myContent" oder,

8What you see is what you get.

17

2 Grundlagen

wie im Beispiel oben beim Button gezeigt, als freier Text innerhalb des Elementsangegeben werden.

Mithilfe von Containerelementen können Elemente in XAML fast beliebig ineinanderverschachtelt werden. Ein Containerelement kann mehrere Elemente enthalten unddiese auf eine bestimmte Art und Weise anordnen. So werden in einem StackPanel alleElemente übereinander gestapelt, während sie in einem Grid in Zeilen und Spalten an-geordnet und auf einem Canvas frei durch Angabe ihrer Koordinaten platziert werdenkönnen.

Zusätzlich du den Attributen, die ein Element ohnehin hat, können ihm Attached Pro-perties gegeben werden, mit denen umgebende Elemente wie zum Beispiel Containe-relemente neue Eigenschaften an ihre Kindelemente vererben können. Auf diese Artund Weise können je nach Kontext, in dem ein Element auftaucht, neue Eigenschaf-ten hinzugefügt werden. Als konkretes Beispiel sei das Containerelement DockPanelgenannt. Es erlaubt das „andocken“ von Elementen oben, unten, rechts und links ineinem Fensterbereich. Ein Element kann dann mithilfe von DockPanel.dock="Right"angeben, dass es rechts im Fenster angedockt werden möchte.

2.6.2 Code-Behind

Zu einem gegebenen Fenster Window.xaml existiert fast immer eine Code-Behind-Dateimit dem Namen Window.xaml.cs, in der zusätzliche Funktionalität, die nicht durchXAML-Code ausgedrückt werden kann, untergebracht werden kann. Im einfachstenFall ist die Datei gar nicht nötig, in komplexeren Fällen erhält sie Ereignishandler undkann Teile der Geschäftslogik eines Programms enthalten. Die Code-Behind-Dateikann zum Beispiel in C# oder Visual Basic geschrieben werden.

Im Allgemeinen ist im Code-Behind-File eine partielle Klasse implementiert, die iden-tisch mit der Klasse des Fensters ist.

2.6.3 Datenkontext und Datenbindung

Der Datenkontext ist eine spezielle Eigenschaft, die von Fenstern oder ähnlichen Gra-fikelementen bereitgestellt wird, und die verwendet werden kann, um in FensternDaten aus der Programmlogik verfügbar zu machen (vgl. [7, Kap. 22.3.3]). Wenn derDatenkontext gesetzt ist, kann im XAML-Code des Fensters auf Daten aus dem Da-tenkontext zugegriffen werden und die Daten können somit auf der Benutzeroberflächeangezeigt werden.

18

2.6 Windows Presentation Foundation (WPF)

Zunächst wird der Datenkontext eines Fensters standardmäßig auf das Objekt desFensters selbst gesetzt. Zusätzliche Eigenschaften (zum Beispiel Strings oder Inte-gervariablen), die in der Code-Behind-Datei als öffentliches Property deklariert sind,können dann im XAML-Code referenziert werden. Es kann aber auch eine andereKlasse als Datenkontext ausgewählt werden, indem der Datenkontext des Objektsexplizit gesetzt wird. Aus dem Code-Behind-File ist diese Zuweisung auf folgende Artund Weise möglich:

1 this.DataContext = new Customer ();

Die Verwendung der Eigenschaft FirstName des Customers kann dann im XAML-Codeüber ein Binding geschehen:9

1 <TextBox Text="{Binding Path=FirstName}" />

Diese Funktionalität erleichtert die Trennung von grafischer Oberfläche und Pro-grammlogik in der WPF-Anwendung erheblich, denn der View (das Fenster) kannseine Daten aus einem anderen Objekt (dem Datenkontext) beziehen und diese sogarverändern ohne dass das andere Objekt das Fenster kennen muss (im Beispiel obenkennt die Klasse Customer den View nicht). Auch EventHandler für Buttonklicks oderInhalte von im Fenster angezeigten Listen können mit dieser Technik im Datenkontextimplementiert werden.

2.6.4 Beispiel

Der grundlegende Aufbau einer WPF-Applikation wird im folgenden Abschnitt an-hand eines Beispiels erklärt. Die Anwendung „FileDeleter“ bietet dem Nutzer eineEingabemaske mit einem Textfeld an, in das eine zu löschende Datei eingetragen wer-den kann (siehe Abbildung 5). Mit einem Klick auf den Button „Delete File“ wird dieDatei gelöscht.

Das Hauptfenster der Anwendung ist in der Datei MainWindow.xaml definiert. Darinwerden bestimmte Properties (wie zum Beispiel Title und Height) gesetzt und dieKindelemente des Fensters – hier ein StackPanel – eingefügt. Das StackPanel ist einContainerelement, das weiter einen TextBlock, eine TextBox und einen Button ent-hält und diese im Fenster aufeinandergestapelt darstellt. Auch im StackPanel, in denTextfeldern und im Button können Eigenschaften gesetzt werden. Als Datenkontextfür das Fenster ist in diesem Fall die Klasse MainWindow selbst gewählt worden. Da dies

9Zusatzoptionen können die Richtung der Bindung beschränken und damit verhindern, dass ausdem Fenster heraus die Werte im Datenkontext verändert werden.

19

2 Grundlagen

Abb. 5: Eingabemaske der Anwendung FileDeleter

dem Standardverhalten entspricht, muss der Datenkontext nicht mehr explizit gesetztwerden.

Ein Ausschnitt von MainWindow.xaml ist in Listing 6 dargestellt. Einige der Eigenschaf-ten des Elements <Window> sind dabei zur besseren Lesbarkeit ausgelassen worden.

1 <Window x:Class="FileDeleter.MainWindow"2 Title="File Deleter" Height="120" Width="250">3

4 <!-- Displayed Window contents -->5 <StackPanel Margin="5">6 <TextBlock HorizontalAlignment="Left">7 Filename8 </TextBlock >9 <TextBox Name="DelFile" HorizontalAlignment="Left"

10 Width="230" Margin="0,5,0,5">11 </TextBox >12 <Button Click="ButtonBase_OnClick" HorizontalAlignment="Left"13 Width="70">14 Delete File15 </Button >16 </StackPanel >17 </Window >

Listing 6: Beispieldatei MainWindow.xaml

Die Code-Behind-Datei – MainWindow.xaml.cs – enthält die partielle Klasse MainWindow.Darin ist ein EventHandler für das „Button-Click-Event“ des im XAML-Code defi-nierten Buttons implementiert, der auf das Feld DelFile aus dem Fenster zugreifenkann, um den Dateinamen der zu löschenden Datei auszulesen:

1 private void ButtonBase_OnClick(object sender , RoutedEventArgs e) {2 string filename = DelFile.Text;3 /* Delete file ... */

20

2.6 Windows Presentation Foundation (WPF)

4 }

Button und Handler werden im XAML-Code mit Click="ButtonBase_OnClick" mitein-ander verknüpft (siehe Listing 6, Zeile 12).

2.6.5 Model-View-ViewModel (MVVM)

Wird WPF in einem Softwareprodukt eingesetzt, so kommt oftmals auch das Design-muster Model-View-ViewModel (kurz MVVM) zum Einsatz, mit dem die grafischeOberfläche einer Anwendung von der dahinter liegenden Geschäftslogik getrennt wer-den kann. Der grundlegende Aufbau dieses Patterns ist in Abbildung 6 visualisiert.

Bei MVVM wird jedes einzelne Fenster als View, das Datenmodell als Model und diedazwischen vermittelnden Einheiten als ViewModels bezeichnet.

View ViewModel Model

Binding

Commands

Function calls

Return values

Abb. 6: Visualisierung MVVM, Quelle: Eigene Darstellung nach [5]

MVVM hat gewisse Ähnlichkeiten mit dem Muster MVC (Model View Controller),der Controller im MVC wird allerdings pro View durch ein ViewModel ersetzt. EineVerbindung von View und ViewModel kann in der Praxis erreicht werden, indemdas ViewModel als Datenkontext des Views gesetzt wird. Steuerelemente im Viewkönnen dann durch ein Binding mit Properties im ViewModel verknüpft werden. DerView kann mithilfe von Commands Befehle an das ViewModel senden. Dafür müssenim ViewModel Command-Objekte als öffentliche Properties vorhanden sein. Auf denAufruf eines Commands hin kann das ViewModel Aktionen im Model auslösen undetwaige Rückgabewerte speichern. Das Model muss dazu keine Referenzen auf dasViewModel haben.

Ein entscheidender Vorteil des Model-View-ViewModels ist, dass das ViewModel nichtzwangsweise den View kennen muss. Werden Commands für die Auslösung von Funk-tionen am ViewModel und Datenbindungen für die Übermittlung von Daten zwischenView zum ViewModel verwendet, kann das ViewModel vollständig ohne den View aus-kommen. Auf die Art und Weise kann der View sehr leicht ausgetauscht werden, odersogar durch einen Unit-Test ersetzt werden, sodass ein automatisiertes Testen vongroßen Teilen der grafischen Oberfläche und angehängter Funktionen möglich wird.

21

3 Analyse und Planung

3 Analyse und Planung

Um die Anforderungen an die neue Software besser ermitteln zu können, wird eineIST-Analyse durchgeführt, die den aktuellen Ablauf bei der Erstellung von Maschi-nensoftware am Standort Oelde erläutert.

Die Ergebnisse der IST-Analyse sind in diesem Kapitel zusammengefasst. Im An-schluss daran finden sich die daraus resultierenden systembezogenen und fachlichenAnforderungen an die neue Software.

3.1 IST-Analyse

3.1.1 Maschinenentwicklung

Im Folgenden wird ein vereinfachter Ablauf bei der Abwicklung einer Bestellung einerneuen Maschine kurz abgerissen. Die einzelnen Schritte sind auch in Abbildung 7dargestellt.

Konstruktion:P&ID zeichnen

HW Design:Komponentendefinieren,

Schaltschrankplanen undzeichnen

SW Design:Steuerungssoft-ware entwickeln

Test undInbetriebnahme

Abb. 7: Vereinfachter Ablauf Maschinenentwicklung

Durch die Abteilung Konstruktion wird zunächst die Anlage selbst als Piping andInstrumentation Diagram (genannt P&ID) mitsamt sämtlichen Separatoren oder De-kantern, Motoren, Ventilen und Rohrleitungen gezeichnet (Schritt 1). Aus dem P&IDwird im Bereich Hardware Design der Schaltplan erstellt und es wird in einem Excel-Dokument zusammengetragen, welche Komponenten mit genau welchen Eigenschaf-ten und Ausprägungen später in das System eingebaut werden (Schritt 2). DieseKomponenten werden Module genannt. Sie sind in verschiedene Typen aufgeteilt (bei-spielsweise gibt es in dem Excel-Dokument Tabellenblätter für Motoren, Ventile oderDigitaleingänge) und jedes Modul hat eine eindeutige P&ID-Nummer und eine Mo-dulnummer, über die es identifiziert werden kann.

22

3.1 IST-Analyse

Von der Abteilung Software Design wird auf Basis der Hardwareliste die Steuerungs-software der Anlage entwickelt (Schritt 3, dieser Ablauf ist im Abschnitt 3.1.2 detail-liert erläutert). Im Anschluss daran kann die Software auf die Steuerung aufgespieltund die Anlage getestet werden, bevor sie zum Kunden geliefert und in Betrieb ge-nommen wird (Schritt 4).

3.1.2 Softwareerstellung allgemein

Die Entwicklung der Steuerungssoftware wird von der Abteilung Software Design, un-terstützt von den Tools Siemens SIMATIC STEP 7 oder Siemens TIA Portal, durch-geführt. Die Auswahl des Tools hängt dabei vor allem von der eingebauten Steuerungund der gewünschten grafischen Oberfläche ab. Die Siemens 300er oder 400er-Seriensind schon länger auf dem Markt und können noch mit STEP 7 programmiert werden;für die neuen Steuerungen der 1200er- oder 1500er-Serien ist als Entwicklungsumge-bung das TIA Portal zwingend erforderlich.

Bei der Erstellung der Software müssen unter anderem Modulbausteine und Daten-bausteine angelegt werden, die dafür sorgen, dass jedes einzelne Modul (also jedesVentil, jeder Motor, jeder Sensor. . . ) der Anlage korrekt angesteuert wird.

Deswegen wird zunächst erklärt, was Modulbausteine, Modulaufrufe und Datenbau-steine sind, bevor die Entwicklungsabläufe bei der Softwareerstellung mit STEP 7 undmit dem TIA Portal erläutert werden.

Modulbausteine

Im Maschinenprogramm wird pro Modulart genau eine (AWL- oder SCL-)Funktionimplementiert, die die Steuerung eines entsprechenden Moduls übernimmt. In derFunktion für Ventile werden beispielsweise Timer überprüft, die anzeigen, wann dasVentil geöffnet oder geschlossen werden muss oder es werden Störungen am Ventilausgelesen und gespeichert. Die Funktion wird Modulbaustein oder Standardbausteingenannt; wenn ein bestimmter Baustein gemeint ist, wird oft der Name des Moduls vordem Namen des Bausteins angefügt (Motorbaustein, Analogeingangsbaustein . . . ).

Der Standardbaustein wird im Programm einmal pro Modul aufgerufen, um diesesanzusteuern, und ihm werden benötigte Daten, wie zum Beispiel Hardware-Adressenvon Sensoren oder Aktoren übergeben. Je nach Modulart hat der Baustein bis zu 30Funktionsparameter.

Das folgende Listing (7) beinhaltet ein Beispiel für einen Modulaufruf eines Ventilbau-steins (WSO_STD_VALVE), der in der Sprache SCL geschrieben ist. Einige der Parameterwerden zur besseren Lesbarkeit ausgelassen. Der vollständige Aufruf hat in diesemFall 24 Parameter.

23

3 Analyse und Planung

1 WSO_STD_VALVE(InX_feedback_open_enable :=FALSE ,2 InX_feedback_open :=% E255.7,3 InX_feedback_closed_enable :=FALSE ,4 InX_feedback_closed :=% E255.7,5 InX_reset_manual_mode:=FALSE ,6 QX_man_open :=# dummy_bool ,7 QX_man_close :=# dummy_bool ,8 QX_fault :=WSO_STD_VALVE_ALARM.alarm_V000 ,9 Daten:= VALVE_DB.V000);

Listing 7: Beispiel für einen Modulaufruf in SCL (gekürzt)

Die Parameter, die im Funktionsaufruf eingetragen werden müssen, können aus derHardwareliste abgeleitet werden. Im Endeffekt muss also aus den Daten in der Hard-wareliste ein Stück Programmcode mit einem Funktionsaufruf erstellt werden. Ab-bildung 8 zeigt einen kleinen Ausschnitt aus der Hardwareliste, hier speziell das Ta-bellenblatt, in dem die Ventile enthalten sind. Für jede Zeile in diesem Tabellenblattwird genau ein Ventilmodul in der Software angelegt.

Abb. 8: Ausschnitt aus der Hardwareliste mit Moduldaten

Es wird schnell klar, dass in einer Anlage mit 500 Ventilen die Erstellung der Funkti-onsaufrufe per Hand sehr viel Zeit in Anspruch nehmen würde und äußerst fehleranfäl-lig wäre. Aus diesem Grund werden die Bausteine automatisiert erstellt. Dafür wurdeein Programm namens bgen entwickelt, das in Abschnitt 3.1.3 vorgestellt wird.

Wie genau der Modulbaustein und der Funktionsaufruf aussieht, hängt natürlich vonder verwendeten Programmiersprache ab. Werden Projekte mit Siemens STEP 7 ent-wickelt, so wird der Baustein fast immer mit AWL programmiert, bei Verwendungdes TIA Portals wird SCL eingesetzt.

24

3.1 IST-Analyse

Datenbausteine

Zusätzlich zum den oben beschriebenen Funktionsaufrufen muss bei der Erstellungvon Maschinensoftware mindestens ein Datenbaustein pro Modulart erzeugt werden.Datenbausteine werden von Siemens-Steuerungen verwendet, um Speicherbereichefestzulegen, in denen die SPS Daten ablegen und abrufen kann. Auch die HMIs könnendiese Datenbereiche auslesen, um dem Benutzer den Status der Steuerung anzuzei-gen.

Für jedes Modul, das verwendet werden soll, muss ein Eintrag in einem Datenbausteinvorhanden sein, damit in der SPS Speicher für die Daten dieses Moduls reserviertwird. Auf eine Beschreibung des genauen Aufbaus eines Datenbausteins soll an dieserStelle verzichtet werden, da bei der automatisierten Erstellung von Datenbausteineneine ähnliche Technik wie bei der Erstellung von Modulaufrufen verwendet werdenkann.

Die Daten für den Datenbaustein finden sich ebenfalls in der Hardwareliste und esmuss damit auch hier wieder aus der Liste Quelltext erstellt werden.

3.1.3 Softwareerstellung mit STEP 7 (bgen)

Bei Verwendung von Siemens STEP 7 wird ein neues STEP 7-Projekt angelegt. Indieses müssen alle Komponenten eingepflegt werden, die in der Hardwareliste vor-handen sind und es müssen enstprechend Modulaufrufe und Datenbausteine erstelltwerden. Der Quellcode des Maschinenprogramms wird in diesem Fall zu großen Teilenin der Sprache AWL geschrieben.

Um den manuellen Arbeitsaufwand bei der Erstellung der Modulaufrufe und Daten-bausteine zu reduzieren – wie oben erwähnt, können in großen Anlagen mehrere hun-dert Module vorhanden sein – existiert ein Tool namens bgen („Baustein Generator“),das aus dem Excel-Dokument Bausteine, also Modulaufrufe und Datenbausteine, ge-neriert und diese selbstständig in das STEP 7-Projekt der Anlage einspielt.10

Der Quellcode von bgen ist in Visual Basic for Applications geschrieben und befindetsich in einem Excel-Dokument, das für jedes neue Projekt kopiert wird und in dasdann per „Copy and Paste“ die Daten aus der Hardwareliste eingetragen werden. DasProgramm wird über einige Buttons im Menüband von Excel gesteuert. Im bgen-Dokument sind diverse bedingte Formatierungen11 eingerichtet, die das anschließende10Auch für die ältere Siemens-Entwicklungsumgebung STEP 5 hat es schon bgen-Versionen gegeben.

Die erste Version wurde bereits vor der Einführung von Microsoft Excel eingesetzt.11Bei „Bedingter Formatierung“ handelt es sich um eine Funktionalität von Microsoft Excel, die es

möglich macht, Zellfarben oder andere Formatwerte durch Bedingungen zu steuern. So könnenzum Beispiel Zellen mit einem negativen Wert automatisch rot eingefärbt werden.

25

3 Analyse und Planung

Prüfen der Module, das ebenfalls von der Abteilung Software Design durchgeführtwird, erleichtern und einige Excel-Formeln, die die Daten für die nachfolgende Verar-beitung aufbereiten.

Abbildung 9 zeigt vorab eine Zusammenfassung des Ablaufs bei der Verwendung vonbgen. Aus den Moduldaten werden die benötigten Bausteine generiert, diese werdendann in STEP 7 importiert und können optional anschließend direkt in eine ange-schlossene SPS geladen werden.

Moduldaten zu-sammentragen

Quellcode-generierung

Import inSTEP 7 Laden in Gerät

Abb. 9: Zusammenfassung Ablauf von bgen

Quellcodegenerierung mit Modulvorlagen

Außer den Moduldaten sind in dem bgen-Dokument Vorlagen (auch Templates ge-nannt) für die zu generierenden Modulaufrufe und Datenbausteine enthalten; essentiellhandelt es sich dabei um ASCII-Texte, die speziell gekennzeichnete Platzhalter (auchkeywords) für Variablen enthalten. Sie sind in einem separaten Tabellenblatt abge-legt. Da für jede Modulart die Funktionsaufrufe und Datenbausteine anders aussehen,sehen auch die Vorlagen für jede Modulart anders aus.

Es gibt einen Platzhalter für jede Eigenschaft, die ein Modul haben kann. Beispielebei einem Ventil sind Module für die Modulnummer, PID für die P&ID-Nummer oderFBO für die Eigenschaft „Feedback open“, die anzeigt, ob das Ventil eine Rückmeldungzu seinem Status liefert.

Das folgende Listing (Listing 8) zeigt einen Ausschnitt aus einem Modultemplate fürein Ventil. Wie auch in Listing 7 ist die Programmiersprache in diesem Beispiel SCL.Die Platzhalter werden hier gekennzeichnet, indem sie mit einem @-Symbol umschlos-sen werden. Sie finden sich auch immer als Spaltenüberschrift im Excel-Dokumentwieder (siehe Abbildung 8 auf Seite 24).

Pro Zeile in einem Tabellenblatt generiert bgen mithilfe der Templates einen Funkti-onsaufruf bzw. einen Teil des Datenbausteins, indem es die Platzhalter in der Vorlagedurch die passenden Werte aus der Tabelle ersetzt. Auf diese Art und Weise entstehtein Modulaufruf, wie er in Listing 7 zu sehen ist.

Genau 100 der Funktionsaufrufe werden zu einer Gesamtfunktion zusammengefasstund mit einem Header und einem Footer versehen. Header und Footer bestehen aus

26

3.1 IST-Analyse

1 // @Module@ @PID@2 // --------------------------------------------------3 WSO_STD_VALVE(InX_feedback_open_enable :=@EnFBO@,4 InX_feedback_open :=%E@FBO@,5 InX_feedback_closed_enable :=@EnFBC@,6 InX_feedback_closed :=%E@FBC@,7 InX_reset_manual_mode:=FALSE ,8 QX_man_open :=# dummy_bool ,9 QX_man_close :=# dummy_bool ,

10 QX_fault :=WSO_STD_VALVE_ALARM.alarm_@Module@,11 Daten:= VALVE_DB.@Module@);

Listing 8: Beispiel für ein Modultemplate in SCL (gekürzt)

weiterem AWL-Quellcode, der die einzelnen Funktionsaufrufe zu einer Funktion machtund wie auch die Templates im bgen-Dokument abliegt. Insgesamt entsteht mit Hea-der und Footer ein ausführbarer Baustein, der von der SPS abgearbeitet werden kann.Er wird auf der Festplatte abgespeichert – sowohl für die Funktionsaufrufe als auchfür die Datenbausteine ist die Dateiendung .awl. Die Erstellung der Modulaufrufe istdamit abgeschlossen.

Weitere Funktionen von bgen

Als nächsten Schritt kann bgen die generierten Dateien in das passende STEP 7-Projekt importieren. Welche Dateien generiert werden sollen, kann vorher über eineListe mit CheckBoxen angegeben werden. Mithilfe dieser Liste können ausgewählteDateien auch gelöscht werden. Für den Import wird die VBA-Schnittstelle genutzt,die STEP 7 hierfür zur Verfügung stellt. Über eine weitere Funktion kann der Pro-grammcode übersetzt und auf eine angeschlossene SPS übertragen werden.

bgen kann konfiguriert werden: Es kann eingestellt werden, wie viele Aufrufe proModul maximal erstellt werden sollen, in welchem Ordner die fertigen Funktionenabgelegt werden sollen oder welche der generierten Funktionen in STEP 7 importiertwerden sollen.

Versionsverwaltung in bgen

Die Inhalte eines bgen-Dokuments sind in Abbildung 10 noch einmal zusammenge-fasst. Sie bestehen aus den Moduldaten, den Vorlagendateien und dem VBA-Quell-code des Programms.

27

3 Analyse und Planung

Moduldaten(getrennt nachModulart)

Vorlagentexte fürModulaufrufe undDatenbausteine

VBA-Quellcodedes Programms

Abb. 10: Inhalte eines bgen-Excel-Dokuments

Da sich der Quellcode von bgen ausschließlich in der Excel-Tabelle befindet, ist eineVersionsverwaltung des Codes nicht möglich. Es existieren viele verschiedene Ver-sionen des Tools; je älter die Maschinensoftware, desto älter im Allgemeinen auchdas verwendete bgen. Auch die Vorlagen für die Modulbausteine und Datenbausteineliegen im Excel-Dokument ab und werden für alte Projekte nicht mehr aktualisiert.

3.1.4 Softwareerstellung mit TIA Portal

Wird das TIA Portal zum Erstellen von Maschinensoftware verwendet, so müssen auchhier die Module aus der Hardwareliste im TIA-Projekt eingetragen werden. Andersals bei Verwendung von STEP 7 werden die Module hier nicht in AWL, sondern inder neueren Programmiersprache SCL erstellt. Es werden allerdings – wie bei AWL –auch hier Modulbausteine, Bausteinaufrufe und Datenbausteine benötigt.

Für das TIA Portal gibt es kein Tool wie bgen, mit dem Aufrufe und Datenbausteineautomatisiert generiert werden können. Eine Portierung von bgen auf die Verwen-dung mit TIA ist nicht möglich, da die von bgen verwendete VBA-Schnittstelle vomTIA Portal nicht mehr unterstützt wird, und von GEA auch nicht erwünscht, weil imExcel-Dokument keine Versionsverwaltung von Quellcode und Vorlagendateien mög-lich ist.

Damit Software für Anlagen mit dem TIA Portal erstellt werden kann, muss also einneues Programm entwickelt werden, mit dem die Module im TIA Portal automatischgeneriert werden können.

3.2 Anforderungen

Um auch für das TIA Portal Software generieren zu können, soll ein neues Tool erstelltwerden, das die Bausteingenerierung im TIA Portal automatisiert. Die konkretenAnforderungen an das Tool sind in diesem Kapitel zusammengetragen. Es werdenzuerst die systembezogenen Anforderungen und dann die fachlichen Anforderungendargelegt.

28

3.2 Anforderungen

Da die Software mit dem Vorgehensmodell Scrum entwickelt wird, werden die Anfor-derungen inkrementell erstellt und zur Laufzeit des Projektes häufig verändert. Diehier dokumentierten Anforderungen spiegeln den finalen Stand nach Fertigstellungder Software wieder.

Ziel ist es, die Funktionen des Programms bgen in eine neue Programmiersprache undfür eine Verwendung mit dem Siemens TIA Portal zu portieren und die Funktionalitätzu erweitern. Zur Steuerung der Anwendung soll eine grafische Oberfläche entwickeltwerden, über die zentrale Funktionen inklusive dem Generieren der Quellcodedateienaus einem Excel-Dokument und der Import der fertigen Dateien in das TIA Portalerreichbar sind.

Angelehnt an den Namen des alten Generators bgen („Baustein Generator“), soll dieneue Software GerTi (für „Generator for TIA“) heißen.

3.2.1 Systembezogene Anforderungen

Die systembezogenen Anforderungen eines Projektes legen die zu verwendende Hard-und Software fest.

Die Zielplattform des Programms sind Standard-PC-Arbeitsplätze mit Windows 7(und aufsteigend). Auf den Rechnern muss sowohl das Siemens TIA Portal V13 alsauch das Add-on TIA Openness installiert sein. Eine Installation von Microsoft Excelwird für das Programm nicht vorausgesetzt, sollte aber in der Praxis stets auf denArbeitsplätzen vorhanden sein.

Das Auslesen der Moduldaten aus der Excel-Datei soll gestützt von den beiden APIsOpenXML und ClosedXML abgewickelt werden. Die Vorlagendateien sollen in einemGit-Repository verwaltet werden und daraus bei Bedarf heruntergeladen werden. DerImport der Dateien in das TIA Portal soll mithilfe von TIA Openness geschehen.

Als Entwicklungs-Framework wird Microsoft .NET in der Version 4.5 festgelegt. Fürdie grafische Oberfläche wird WPF, gestützt von MVVM, verwendet.

Das Projekt soll mithilfe von C# im Visual Studio entwickelt werden. Der Quellco-de des Projekts wird in einem Git-Repository verwaltet und auf einem Git-Serverder GEA zur Verfügung gestellt. UnitTests sollen mit Microsofts UnitTesting Frame-work erstellt und automatisiert auf einem Jenkins-Buildserver ausgeführt werden. DieProjektorganisation wird über JIRA abgewickelt und die Dokumentation soll auf derConfluence Plattform geführt werden. Mithilfe von JIRA werden die Anforderungenauch priorisiert und aktuell gehalten. Neue Anforderungen werden im Backlog desSoftwareprojektes eingetragen und im Laufe eines Sprints abgearbeitet.

29

3 Analyse und Planung

Für den Quellcode und alle darin enthaltenen Kommentare sowie die grafische Benut-zeroberfläche wird als Sprache Englisch festgelegt. Auch auf der Organisationsplatt-form JIRA wird auf Englisch gearbeitet. Die Dokumentation in Confluence hingegenwird vollständig in deutscher Sprache verfasst.

Qualitätsziele

Folgende Qualitätsziele werden bei der Entwicklung von GerTi angestrebt:

• Stabilität: Das Programm darf wegen fehlerhaften Dateien (sowohl Templatesals auch Excel-Dateien und TIA-Projekte) nicht abstürzen und muss eine ver-ständliche Fehlermeldung an den Benutzer melden.

• Verständlichkeit: Der Quelltext des Programms muss gut dokumentiert undverständlich aufgebaut sein.

• Erweiterbarkeit: Das Programm soll in Zukunft auch mit anderen Steuerungs-softwares (außer TIA) nutzbar sein.

• Effizienz: Auch bei der Generierung vieler Bausteine soll das Programm nichtviel Zeit benötigen.

• Wartbarkeit: Bei Änderungen an Fremdkomponenten, sowie bei Refactoringsund Programmerweiterungen soll das Programm leicht anpassbar sein.

3.2.2 Fachliche Anforderungen

Die Details zu den fachlichen Anforderungen des Programms sind in den nächstenAbschnitten zu finden.

Beim Start des Programms müssen die Dateipfade zum Excel-Dokument und zumTIA-Projekt sowie diverse Einstellungen gesetzt werden, die für jedes Anlagenprojektverschieden sind. Damit schnell zwischen mehreren Projekten umgeschaltet werdenkann, ohne die Pfade neu einzugeben, ist pro Anlagenprojekt eine Konfigurationsdateivorgesehen, aus der diese Daten geladen werden können.

Versionsverwaltung der Template-Dateien

Die Vorlagendateien für die Codegenerierung sollen nicht – so wie bei bgen – in derExcel-Datei zusammen mit den Moduldaten gespeichert werden, sondern als Text-dateien vorliegen, die mithilfe von Git unter eine Versionsverwaltung gestellt werden

30

3.2 Anforderungen

können. Die Templates sind nicht mehr in AWL geschrieben, sondern in SCL, da-mit die Verwendung mit neueren Steuerungsgenerationen gesichert bleibt. Die Datei-en werden für jedes Anlagenprojekt einzeln im Ordner Templates im Verzeichnis desExcel-Dokuments abgelegt.

Bei Änderungen an diesen Dateien soll GerTi automatisch den aktuellen Stand auseinem zentralen Git-Server herunterladen. Das Update der Dateien muss allerdingsauch abgeschaltet werden können – es gibt alte Versionen der Steuerungssoftware,die mit den neuen Vorlagen nicht mehr funktionieren würden. Ob das Update an-oder ausgeschaltet ist, wird in der Konfigurationsdatei gespeichert. Falls der Ord-ner Templates noch gar nicht vorhanden ist, soll GerTi das gesamte Git-Repositoryherunterladen („clonen“).

Der Pfad des Git-Servers, auf dem die Templates liegen, muss zentral konfiguriertwerden können (nicht projektbasiert, sondern auf die gesamte Anwendung GerTi be-zogen), aber nicht in der grafischen Oberfläche geändert werden können.

Quellcodegenerierung

Die Moduldaten, die zur Codegenerierung verwendet werden, sollen (genau wie beibgen) aus einer Excel-Datei ausgelesen werden. Dabei wird der Tabellenblattnameverwendet, um festzustellen, in welchem Blatt welches Modul zu finden ist, und umeine Referenz zu den Vorlagendateien herzustellen.

Aus den Vorlagendateien und der Excel-Datei werden vollständige SCL-Dateien ge-neriert, die in einem separaten Ordner auf der Festplatte abgespeichert und auch inder grafischen Oberfläche des Programms als Liste angezeigt werden. Als Dateien-dung ergibt sich .scl beziehungsweise .db für die Datenbausteine. Die generiertenDateien werden in einem Ordner mit dem Namen Generated abgelegt, der im gleichenVerzeichnis wie das Excel-Dokument liegt.

Tritt bei der Generierung ein nicht kritischer Fehler auf (zum Beispiel wenn ein Feldin der Vorlagendatei als Platzhalter markiert ist, aber nicht in der Excel-Datei alsSpaltenname auftritt), so wird das Ereignis geloggt und dem User auf der GUI an-gezeigt, aber mit der Generierung fortgefahren. Bei kritischen Fehlern (zum Beispielbei einer fehlerhaften Excel-Datei, oder beim Fehlen von Vorlagendateien) wird derProzess abgebrochen, und der User wird mit einem Dialogfenster über den Fehlschlaginformiert. Zusätzlich wird die Meldung geloggt.

So wie bgen genau 100 Module zu einer Datei zusammenfasst und dann eine neue Da-tei beginnt, soll auch bei GerTi eine Trennung der Modulaufrufe auf mehrere Dateienmöglich sein. Die Anzahl der Module pro Datei soll allerdings über die Konfigurati-onsdatei pro Projekt einstellbar sein.

31

3 Analyse und Planung

Bei der Entwicklung des Programms sollen die Datenquellen (Excel für die Modulda-ten, Textdateien für die Vorlagendaten) austauschbar realisiert sein und in Zukunftleicht durch andere Datenquellen ersetzt werden können.

TIA-Import

In SCL geschriebene Quellcode-Dateien können im TIA Portal als sogenannte externeQuellen in einen Controller importiert werden. Sie sind dann im jeweiligen Controllerim Ordner Externe Quellen sichtbar.

GerTi soll ein bestehendes TIA Projekt öffnen und die bei der Generierung entstan-denen Quellcodedateien als externe Quelle in das Projekt laden. Über die grafischeOberfläche soll ausgewählt werden können, welche der verfügbaren Dateien aus demOrdner Generated importiert werden sollen. Es muss beim Import darauf geachtet wer-den, dass es Projekte gibt, in denen zusätzlich zu der eigentlichen CPU eine „leereCPU“ vorhanden ist. Es muss die korrekte CPU für den Import der Quellen ausge-wählt werden.

Einmal importiert, können die Bausteine im TIA Portal übersetzt werden. GerTi sollden Übersetzungsvorgang bei allen importierten Dateien anstoßen und etwaige Fehlerloggen und an den User weitergeben.

Zur Kommunikation mit dem TIA Portal soll die TIA Portal Openness Schnittstelleverwendet werden, die bereits in Kapitel 2.2.2 erläutert wurde.

Logger

Falls im Programmverlauf Ereignisse auftreten, über die ein User informiert werdensoll, so sollen diese geloggt werden. GerTi soll verschiedene Arten von Loggern zurVerfügung stellen: einen, der die Logdaten in eine Textdatei schreibt und einen der diegeloggten Texte in einer Liste (eine verkettete Liste oder Vergleichbares) vorhält.

Die Lognachrichten sollen im unteren Bereich der GUI angezeigt werden. Jede derNachrichten soll mit einem Zeitstempel und mit einem Log-Level versehen werden,die beide auch auf der GUI angezeigt werden sollen.

Projektdaten

In einem „GerTi-Projekt“ sollen Daten, die alle zu einem Anlagenprojekt gehören,gespeichert werden. Dazu gehören unter anderem der Pfad zur Eingabedatei (bis-her kann das nur eine Excel-Datei sein) und der Pfad zum TIA-Portal-Projekt. DasProjekt soll auf der Festplatte gespeichert werden und zu einem späteren Zeitpunkt

32

3.2 Anforderungen

wiederhergestellt werden können. Die Dateiendung für gespeicherte Projekte wirdstets .gerti sein.

Vom Programm erzeugte Daten (zum Beispiel Logs oder generierter Quellcode, aberauch die Projektdatei) werden immer in dem Verzeichnis abgespeichert, in dem auchdie Excel-Datei liegt.

Folgende Daten sollen innerhalb eines GerTi-Projekts gespeichert werden können:

• Pfad der Eingabedatei (InputFile, aktuell nur Excel-Dateien)

• Pfad des TIA-Portal-Projekts

• Maximalwerte für zu generierende Module (pro Modul)

• Maximalwert für Funktionsaufrufe pro Datei

• Kennzeichen, ob Vorlagendateien aktuell gehalten werden sollen

• Aktuell für den Import in TIA oder zum Löschen ausgewählte Dateien aus demOrdner Generated

Grafische Oberfläche

Alle der oben beschriebenen Programmfunktionen sollen über die grafische Oberflächeerreichbar sein.

In einem Hauptfenster sollen der Pfad der verwendeten Excel-Datei und ein Buttonzum Generieren der Quellcodedateien angezeigt werden.

In einem zweiten Abschnitt wird der Pfad des TIA-Projektes eingeblendet. Über eineListe mit CheckBoxen soll ausgewählt werden können, welche der verfügbaren Dateienin das TIA Portal importiert werden sollen. Ein Knopf „Import and Compile“ soll dieDateien entsprechend in das TIA Projekt laden und übersetzen. Ein weiterer Knopfsoll alle markierten Dateien auf der Festplatte löschen.

Allgemeine Funktionen des Programms sollen über eine Menüleiste erreichbar sein.Dazu gehören das Anlegen eines neuen Projektes, das Öffnen und Schließen von be-stehenden Projekten und das nachträgliche Ändern von Projektdaten in bestehendenProjekten.

Änderungen an Projekteinstellungen sollen in einem separaten Fenster gemacht wer-den können. Dort sollen die Excel- und TIA-Datei einstellbar sein, und es soll proModulart die Maximalanzahl der zu generierenden Modulaufrufe verändert werdenkönnen. Auch das Update-Kennzeichen für die Vorlagendateien im Git wird hier ge-setzt.

33

3 Analyse und Planung

Die Oberfläche soll übersichtlich und leicht bedienbar sein. Im oberen Bereich desHauptfensters soll ein GEA-Logo angezeigt werden.

34

4 Durchführung

In diesem Kapitel sind die allgemeine Vorgehensweise und der Projektaufbau desneuen Tools dargestellt. Im Anschluss werden in den Abschnitten 4.3 bis 4.7 dieeinzelnen Komponenten der Software genauer beschrieben.

4.1 Agile Softwareentwicklung

Das Projekt wird vollständig nach dem agilen Softwareentwicklungsmodell Scrumdurchgeführt. Das Modell selbst wird als bekannt angenommen und an dieser Stellenicht mehr ausführlich beschrieben.

Abbildung 11 zeigt die organisatorische Projektstruktur von GerTi. Zu Beginn desProjektes werden zunächst die beiden Scrum-Rollen Product Owner und Scrum Mas-ter auf Mitarbeiter der Abteilung Software Design verteilt. Das Scrum-Team bestehtaus einer Hauptentwicklerin, die maßgeblich für die Implementierung der Softwarezuständig ist. Zudem werden fachübergreifend zusammengesetzte Tester-Teams undReviewer-Teams festgelegt, in denen sowohl Softwareentwickler als auch Anwenderdes neuen Tools zu finden sind. Ein Teil der mitwirkenden Personen und auch der

Abb. 11: Entwicklungsteam für GerTi, Quelle: GEA-interne Darstellung

35

4 Durchführung

Product Owner arbeitet bereits seit Jahren mit dem Tool bgen, kennt sich also mitden Anforderungen an die Software sehr gut aus. Darüber hinaus sind einige erfahreneSoftware-Architekten bei der Entwicklung mit im Boot, die die entstandene Strukturbewerten und verbessern können.

Da sich das Projekt über einige Wochen und nicht über viele Monate erstrecken wird,wird als Zeitfenster für einen Sprint eine Woche festgelegt. Am Ende jeder Wochesteht dann eine Sprint-Retrospektive mit einem kurzen Code-Review. In diesem Tref-fen wird auch bereits der nächste Sprint für die kommende Woche geplant. Die imSprint zu bearbeitenden Aufgaben werden dem Product Backlog im JIRA entnom-men. Sie werden mit einem Estimate versehen, das abschätzt, wie viel Aufwand mitder Aufgabe verbunden ist. Während des Sprints können die Aufgaben von den Ent-wicklern im JIRA als in Progress und schließlich als done markiert werden.

Das Backlog wird laufend, auch unter der Woche, mit neuen Aufgaben gefüllt. DieTests und Reviews des Quellcodes finden ebenfalls nicht zu festen Zeiten statt. Viel-mehr können sich Tester und Reviewer den aktuellen Stand des Projektes aus demGit-Repository herunterladen und im Visual Studio damit arbeiten. Bugs oder Ver-besserungsvorschläge können über die Tools JIRA und Confluence kommuniziert wer-den.

Zusätzlich zu den wöchtentlichen Treffen wird ein täglicher Termin für den DailyScrum eingestellt. In diesem etwa 15-minütigen Treffen werden Ergebnisse des letztenTages und Ziele für den aktuellen Tag diskutiert. Dadurch sind alle Beteiligten stetsüber den Projektfortschritt auf dem Laufenden.

4.2 Projektaufbau

Um das Softwareprojekt übersichtlicher und leichter wartbar zu machen, ist es inverschiedene Komponenten aufgeteilt, für die jeweils ein Project im Visual Studioangelegt wird.

Es liegt nahe, die Generierung der Modulaufrufe und den Import der Quellcodedatei-en in das TIA Portal in separate Projects auszulagern. Auch die Logging-Funktionund die Git-Updates der Vorlagendateien werden aus dem Haupt-Project ausgeglie-dert, um die Software besser zu strukturieren. Das zentrale Project, von dem ausdas Programm koordiniert wird, heißt „GerTi“. Da sich in diesem Project auch diegrafische Oberfläche befindet, ist es in drei Unterkomponenten aufgeteilt, um demEntwurfsmuster MVVM gerecht zu werden: Model, View und ViewModel.

Der Projektaufbau ist in Abbildung 12 in Form eines Architekturdiagramms visuali-siert. Man kann erkennen, dass das Model im Projekt GerTi auf die Projekte GitUp-dater, ModuleGenerator und PlcImporter zugreift. Auf das Logger-Projekt wird vonallen Projekten aus zugegriffen.

36

4.2 Projektaufbau

Abb. 12: Architekturdiagramm GerTi

Jedes der Projekte ist für eine oder mehrere der zentralen Anforderungen an dieSoftware GerTi zuständig:

• Logger: Stellt den anderen Projekten eine simple Methode zur Verfügung, mitder diese Logginginformationen speichern können.

• GitUpdater: Lädt alle Template-Dateien für die SCL-Bausteine aus einem Git-Repository herunter und kann das Repository aktualisieren, wenn neue Versio-nen vorhanden sind.

• ModuleGenerator: Verwendet die Template-Dateien und die Modulvorlagenaus dem Excel-Dokument, um Quellcode zu generieren.

• PlcImporter: Öffnet die Anwendung TIA Portal und kann TIA anweisen, einbestimmtes Projekt zu öffnen. In dieses Projekt kann es dann Bausteine impor-tieren und diese übersetzen.

37

4 Durchführung

• GerTi: Enthält die grafische Benutzeroberfläche und zentrale Modelldaten, wiezum Beispiel Dateipfade. Von hier aus werden die Aufrufe zur Generierung vonModulaufrufen oder der Import in das TIA Portal koordiniert und Fehler, alsoExceptions, für den Benutzer entsprechend aufbereitet.

Die folgenden Abschnitte erläutern die fünf Projekte im Detail.

4.3 Logger

Um eine Kommunikationsschnittstelle für das Loggen von Nachrichten zu schaffen,wird die Schnittstelle ILogger erstellt. Diese schreibt eine Methode Log() vor, an dieeine Lognachricht und ein Log-Level der Logmeldung übergeben werden können. Lis-ting 9 zeigt die Definition des Interfaces. Es werden zwei Klassen erstellt, die dasInterface implementieren: TextFileLogger zum Erstellen von Logfiles auf der Festplat-te und ListLogger zum Loggen der Nachrichten in einer IList. Für die Umsetzung desLog-Level wird ein Enum LogLevel mit den Elementen Info, Warn und Error verwendet(siehe Listing 10).

1 public interface ILogger {2 void Log(LogLevel level , string message);3 }

Listing 9: Interface ILogger

1 public enum LogLevel {2 Info , Warn , Error3 }

Listing 10: LogLevel im Logger-Project

Damit bei Verwendung von mehreren Loggern nicht mehrfach hintereinander Log()aufgerufen werden muss und um die Logger zentral zur Verfügung zu stellen, wird einLoggingService eingesetzt. Dieser wird als statische Klasse umgesetzt, der eine Listevon Loggern und zwei Methoden enthält, eine zum Hinzufügen eines Loggers und einezum Loggen einer Nachricht. Letztere hat die gleiche Signatur wie die Methode Log()und gibt die zu loggende Nachricht an alle Logger in der internen Liste weiter. Überfolgende Zeile kann so eine Nachricht an alle Logger gegeben werden:

1 LoggingService.LogMessage(LogLevel.Info , "Log test");

38

4.4 Git-Updater

Die Architektur des Projektes ist in Abbildung 13 zusammengefasst.

Abb. 13: Vereinfachtes Klassendiagramm des Logger-Projekts

Die Logging-Funktionalität wird als separates Projekt im Visual Studio realisiert, dasein eigenes Testprojekt hat. Da der Logger eine so zentrale Funktionalität bereitstellt,ist er in alle anderen Projekte der Solution mit eingebunden. Das Projekt hängt nichtvon anderen Projekten aus der Solution ab und könnte daher auch in Zukunft inanderen Programmen als Bibliothek eingesetzt werden.

4.4 Git-Updater

Da GerTi zum Generieren des Quellcodes die SCL-Vorlagendateien benötigt, müssendiese bei Erstellung eines neuen Projektes zunächst aus einem Git-Repository her-untergeladen werden. Dafür wird auf dem Rechner, auf dem die Software ausgeführtwird, eine funktionsfähige Installation von Git benötigt. Sowohl bei dem Installati-onspfad als auch bei der Adresse des Remote-Repositories, aus dem die Daten geladenwerden, handelt es sich um Daten, die sich nur äußerst selten (wenn überhaupt) än-dern werden. Aus diesem Grund sollen die Daten nicht über die grafische Oberfläche,sondern über eine Konfigurationsdatei einstellbar sein. Die Konfigurationsdatei ver-hindert auch das versehentliche Ändern durch Benutzer, die die Einstellung nichtkennen.

Um dies umzusetzen, wird die Datei App.config gewählt, die stets mit einer C#-Applikation im .NET-Framework ausgeliefert werden kann und die häufig verwendetwird, um das Laden von Assemblies zu steuern (vgl. [2]). Es ist allerdings auch mög-lich, in dieser Datei key-value-Paare zu hinterlegen, die zur Laufzeit im Programmausgelesen werden können. Der Inhalt der Datei wird in Listing 12 gezeigt, Listing 13zeigt die Verwendung im Programm.

39

4 Durchführung

1 <?xml version ="1.0" encoding ="utf -8"?>2 <configuration >3 <startup >4 <supportedRuntime version="v4.0"5 sku=".NETFramework ,Version=v4.5"/>6 </startup >7 <appSettings >8 <add key="gitProgramPath"9 value="C:\ Program Files\Git\bin\git.exe"/>

10 <add key="gitRemotePath"11 value="http :// sv42080boe9230 :8081/r/gerti.git"/>12 </appSettings >13 </configuration >

Listing 12: App.config der Software

1 using System.Configuration;2 // ...3 string key = "gitRemotePath";4 string val;5 val = ConfigurationManager.AppSettings.Get(key);

Listing 13: Verwendung von key-value-Paaren aus der App.config

Durch eine Änderung an der App.config können nachträglich die Pfade der git.exe unddes Remote-Repositories angepasst werden, ohne dass Änderungen am Programmcodevon GerTi notwendig sind.

Aufruf der git.exe

Für die Aktualisierung der Vorlagendateien wird eine neue Klasse, Updater, im ProjektGitUpdater erstellt. Das Ausführen von Git selbst wird in eine separate, private Funkti-on in dieser Klasse ausgelagert, um Code-Redundanzen zu vermeiden. Dieser Funktionwerden die Argumente, die beim Aufruf von Git angegeben werden, als String über-geben (zum Beispiel "push" oder "fetch --all"). Um sowohl die Standard-Ausgabe alsauch die Standard-Errorausgabe des Programms an die aufrufende Funktion zurück-geben zu können, werden out-Parameter12 verwendet. Als Rückgabewert der Funktionwird der ExitCode des Programmaufrufs von Git zurückgegeben13.

12In C# müssen Funktionsparameter, die innerhalb einer Funktion verändert werden, mit demSchlüsselwort out gekennzeichnet werden, damit die Variable als Referenz und nicht als Kopieübergeben wird.

13Git gibt im Erfolgsfall stets 0 zurück, im Fehlerfall einen Wert ungleich 0.

40

4.5 ModuleGenerator

1 private int GitExecute(string arguments , out string stdout , outstring stderr);

Intern verwendet die Methode GitExecute() die Objekte ProcessStartInfo und Pro-cess aus dem Namespace System.Diagnostics, um einen Git-Prozess zu starten undam Ende die Standard-Ausgabe und die Standard-Fehlerausgabe sowie den ExitCodeabzufragen.

Die Aktualisierung der Vorlagendateien kann durch einen Klick in der GUI angesto-ßen werden. Dadurch wird die öffentliche Methode GitRefresh() der Klasse Updaterausgeführt, die überprüft, ob das aktuelle Verzeichnis bereits ein Git-Repository istund in Abhängigkeit davon das angegebene Remote-Repository neu klont, oder dasBestehende aktualisiert. Ist das Update für das aktuelle Projekt ausgeschaltet, so wirddie Update-Funktion vom Haupt-Project aus nicht mehr aufgerufen.

Auch bei dieser Programmkomponente bietet sich, wie schon beim Logger, die Wie-derverwendung in anderen, zukünftigen Projekten besonders an.

4.5 ModuleGenerator

Der Quellcodegenerator bildet das Herzstück des GerTi-Projektes. Bei der Implemen-tierung sind verschiedene Herausforderungen zu beachten: Die Extraktion der Modul-daten aus der Excel-Datei, die Bereitstellung der Modulvorlagen, die Kombinationvon beidem zu funktionsfähigem Quellcode und schließlich das Abspeichern der fer-tigen Dateien. Diese einzelnen Schritte werden in den folgenden Abschnitten genauererläutert.

4.5.1 Laden der Moduldaten

Die Moduldaten sollen laut Anforderungen mithilfe von ClosedXML und OpenXMLaus einer Excel-Datei extrahiert werden.

Damit trotzdem in Zukunft andere Datenquellen möglich sind, wird das InterfaceIDictionaryLoader verwendet, das eine einheitliche Schnittstelle für alle Datenquellenbereitstellt (siehe Listing 15).

Die Moduldaten werden immer pro Modulart extrahiert. Welche Modularten vorhan-den sind, kann mit der Methode GetModuleNames() ermittelt werden. Für eine Excel-Datei sind dies die Namen der Tabellenblätter.

Die eigentlichen Daten werden mit der Methode GetDataForModule() geladen. Dabeiwird mit dem Parameter moduleName die Modulart angegeben und mit dem Parameter

41

4 Durchführung

1 public interface IDictionaryLoader {2 /// <summary >3 /// Retrieve all available module names for this4 /// loader ’s data source.5 /// </summary >6 /// <returns >Module names as a list of strings </returns >7 IList <string > GetModuleNames ();8

9 /// <summary >10 /// Retrieve module data for given module name.11 /// </summary >12 /// <param name=" moduleName">Name of module </param >13 /// <param name=" keywordNames">Properties to retrieve </param >14 /// <returns >List of dictionaries , each containing15 /// keyword -value mappings for one module </returns >16 IList <IDictionary <string , string >> GetDataForModule(string

moduleName , ICollection <string > keywordNames);17 }

Listing 15: Interface IDictionaryLoader

keywordNames wird angegeben, welche Moduleigenschaften geladen werden sollen. DiekeywordNames entsprechen den Namen der Platzhalter, die später in der Vorlagendateiersetzt werden müssen. In der Excel-Datei sind dies die Spaltenüberschriften. Rückga-bewert der Methode ist eine Liste von Dictionaries, von denen jedes genau ein Modulrepräsentiert. Die Keys des Dictionaries sind die Keywords aus dem Methodenaufrufund die Values im Dictionary sind die Moduldaten.

Das Interface wird aktuell ausschließlich von der Klasse ExcelHandler implementiert.Diese Klasse verlangt im Konstruktor den Dateipfad zu einer Excel-Datei, in dersich Moduldaten befinden. Mithilfe von ClosedXML wird die Datei im Konstruktortestweise geöffnet, um schon zu Beginn feststellen zu können, ob die Datei existiertund ob darauf zugegriffen werden kann.

Das folgende Klassendiagramm zeigt den ExcelHandler und das Interface IDictionaryLoader. Private Methoden des ExcelHandlers sind ausgeblendet.

Bei der IST-Analyse hat sich gezeigt, dass häufig parallel zur Verwendung von bgendie Moduldaten in der Excel-Datei noch geändert werden. Damit das Excel-Dokumentparallel zur Verwendung von GerTi noch in Excel geöffnet sein kann, muss GerTi imRead-only-Modus auf das Dokument zugreifen.

Die Spaltenüberschriften müssen im Excel-Dokument nicht zwangsläufig in der erstenZeile und der ersten Spalte stehen. GerTi ermittelt mithilfe von ClosedXML den „usedrange“ des Tabellenblatts, also den Bereich, in dem sich tatsächlich Daten befinden.

42

4.5 ModuleGenerator

Abb. 14: Vereinfachtes Klassendiagramm zum Laden der Moduldaten

Die erste gefüllte Zeile wird als Überschriftenzeile angesehen. Falls für ein angeforder-tes Keyword keine passende Spalte gefunden wird, loggt GerTi eine Warnung. WeitereWarnungen treten auf, wenn Umlaute in den Zelldaten vorhanden sind14, wenn Clo-sedXML eine Formel in Excel nicht auflösen kann15 oder wenn schlicht für ein Modulkein Zellinhalt in einer bestimmten Spalte eingetragen ist16.

4.5.2 Bereitstellung der Modulvorlagen

Um eine SCL-Datei mit Modulaufrufen zu erstellen, wird jeweils eine Vorlage für denHeader und den Footer und eine Vorlage für den eigentlichen Aufruf des Modulbau-steins benötigt. Datenbausteine sind etwas komplizierter aufgebaut und benötigtenneben dem Header und Footer einen Mittelteil und zwei Vorlagen mit Platzhalternfür Variablen-Ersetzungen. So sind insgesamt acht verschiedene Modulvorlagen proModulart nötig. Um im Code nach dem Typ der Vorlage differenzieren zu können,wird ein Enum mit dem Namen Template angelegt (siehe Abbildung 15).

Auch wenn die Modulvorlagen zunächst immer von der Festplatte geladen werden sol-len, wird eine Schnittstelle, ITemplateManager, definiert, mit der die eigentliche Quelleder Daten abstrahiert wird. Das Interface besitzt eine Methode GetTemplate(), die füreinen gegebenen Template-Typen und eine gegebene Modulart den Inhalt der Vorlagezurückgibt:

14Laut einer internen Entwicklerkonvention werden in TIA-Programmen keine Umlaute eingesetzt.Vereinzelt finden sich aber immer noch ältere Programme, in denen diese vorkommen.

15Dies tritt auf, wenn in der Formel spezielle sogenannte „strukturierte Verweise“ auftreten, die mitExcel 2007 eingeführt wurden.

16Für die Codegenerierung stellt dies kein Problem dar, die Übersetzung im TIA Portal wird hier-durch aber möglicherweise scheitern.

43

4 Durchführung

1 string template = templateManager.GetTemplate(Template.ModuleHeader ,2 module);

Die Klasse SclFileManager implementiert dieses Interface und sucht die Vorlagendatei-en unter einem fest vorgegebenen Namen im Ordner Templates, der im Abschnitt 3.2schon erwähnt wurde. Falls eine Vorlage nicht gefunden werden kann, wird eineTemplateNotFoundException geworfen, die speziell für diesen Fall angelegt wird und eineSpezialisierung der FileNotFoundException ist.

Abbildung 15 zeigt den Aufbau des Interfaces und der Klasse SclFileManager.

Abb. 15: Vereinfachtes Klassendiagramm Bereitstellen der Modulvorlagen

4.5.3 Abspeichern der Dateien

Fertiggestellte Quellcodedateien können mit einer Klasse, die das Interface IModule-Exporter implementiert, in eine beliebige Datenquelle geschrieben werden. Dazu stehenzwei Methoden zur Verfügung: Eine für den Export von Modulaufrufen, eine für denExport von Datenbausteinen. Den Methoden werden der zu exportierende String, dieModulart und eine laufende Nummer der Datei übergeben. Die laufende Nummerwird benötigt, da durch die geforderte Aufteilung der Aufrufe auf mehrere Dateienauch verschiedene, durchnummerierte Dateinamen benötigt werden.

Das Interface wird von der Klasse DiskExporter implementiert, der bei der Instanti-ierung die gewünschten Datei-Endungen für Modulaufrufe und Datenbausteine sowiedas Zielverzeichnis auf der Festplatte übergeben werden können. Damit ist die Klasseunabhängig von den zu exportierenen Daten und deren Format.

44

4.5 ModuleGenerator

4.5.4 Quellcodeerstellung

Die Quellcodeerstellung wird für jedes Modul getrennt nach Funktionsaufrufen undDatenbausteinen einzeln durchgeführt. Sie ist in eine neue Klasse, genannt ModGen,gekapselt, die die drei oben erläuterten Funktionen (Laden der Moduldaten, Bereit-stellung der Modulvorlagen, Abspeichern der Dateien) ausführt. Die Klasse hat alsKlassenvariablen einen IDictionaryLoader, einen ITemplateManager und einen IModule-Exporter, die diese Aufgaben übernehmen können.

Im Klassendiagramm Abbildung 16 ist die gesamte Klasse abgebildet. Man kann ne-ben den beiden Methoden GenerateModule() und GenerateDb() auch die drei VariablenmoduleDataHandler, templateManager und exporter erkennen.

Abb. 16: Klassendiagramm Quellcodeerstellung

Im Folgenden wird nur der Ablauf für die Modulaufrufe beschrieben. Die Abwicklungbei der Erstellung von Datenbausteinen ist diesem sehr ähnlich.

Für die Generierung jeder einzelnen Modulart werden die Schritte in Abbildung 17durchlaufen.

Die Erstellung wird von außen für jede einzelne Modulart mithilfe der MethodeGenerateModule() angestoßen. In Listing 17 wird eine vereinfachte Version dieser Me-thode dargestellt. Man kann dabei gut erkennen, dass die Schritte aus Abbildung 17direkt im Code wiederzufinden sind. Mit dem Parameter module wird der Name der

45

4 Durchführung

Laden derVorlagen

Extrahierender Platz-halter

Laden dernötigenModul-daten

„Find-and-Replace“

Export derfertigenStrings

Abb. 17: Ablauf zur Quellcodeerstellung

Modulart angegeben, also zum Beispiel "Valves" oder "Motors". Die Aufteilung derModulaufrufe auf mehrere Dateien mithilfe des Parameters maxRowsPerFile wird zurbesseren Übersicht weggelassen, ebenso wie die Reduzierung der Modulaufrufe auf diein maxRowsTotal angegebene Anzahl und das Hinzufügen von Logginginformationen.

1 public void GenerateModule(string module , int maxRowsPerFile ,2 int maxRowsTotal) {3 // Return if no modules should be generated4 if (maxRowsTotal <= 0)5 return;6

7 // Find template for this module8 string template = templateManager.GetTemplate(Template.Module ,9 module);

10

11 // Find keywords in template12 ICollection <string > keywords = FindKeywords(template);13

14 // Load module data (Excel)15 IList <IDictionary <string , string > moduleData =16 moduleDataHandler.GetDataForModule(module , keywords);17

18 // Get template header19 string result = templateManager.GetTemplate(20 Tempalte.ModuleHeader , module);21

22 // Replace keywords in template using module data23 result += GenererateAllCalls(template , moduleData , keywords);24

25 // Get template footer26 result += templateManager.GetTemplate(Template.ModuleFooter ,27 module);28

29 // Save data30 exporter.SaveModule(result , module , 0);31 }

Listing 17: Methode GenerateModule() (gekürzt)

46

4.6 PlcImporter

In der Methode GenerateAllCalls() (Zeile 23 im Listing) werden die Platzhalter in denVorlagendateien durch die Werte aus den Moduldaten ersetzt. Dafür wird die Funkti-on String.Replace() verwendet. Das Trennzeichen (delimiter), mit dem die Platzhaltergekennzeichnet werden, ist variabel gehalten und kann falls gewünscht im Programm-verlauf geändert werden.

4.6 PlcImporter

Wie in Kapitel 3.2.2 beschrieben, sollen die fertiggestellten SCL-Dateien in ein TIA-Projekt importiert werden. Dazu sind die Schritte in Abbildung 18 nötig.

Laden derOpenness-

DLLs

Startendes TIAPortals

Öffnen desProjektes

Controlleridenti-fizieren

Importund

Compile

Abb. 18: Ablauf zur Quellcodeerstellung

Damit die Referenzen zu den Openness-Bibliotheken zur Laufzeit des Programmsaufgelöst werden können, muss so früh wie möglich im Programmablauf ein Resolvereingehängt werden, der auf ein AssemblyResolve-Event reagieren kann. Dieses Eventwird ausgelöst, wenn eine Assembly zur Laufzeit nicht gefunden werden kann, alsoauch dann wenn die Openness-Bibliothek zum ersten Mal verwendet wird. Der Re-solver durchsucht die Windows-Registry nach der Installation von TIA Portal undkann so die Assembly finden und laden. Siemens hat für einige häufig verwendeteOpenness-Funktionen eine Bibliothek, die TiaPortalOpennessClassLibrary zur Verfü-gung gestellt, in der ein entsprechender Resolver implementiert ist. Mit der FunktionOpennessHelper.PathSearch() wird der EventHandler eingehängt. Im Programm GerTiwird diese Funktion schon bei der Initialisierung der grafischen Oberfläche aufgeru-fen (genauer gesagt wird PathSearch() im Konstruktor der Klasse MainWindowViewModelausgeführt).

Da das Öffnen des TIA-Portals und eines Projektes darin auch ohne Hinzukommeneiner externen Anwendung je nach verwendetem Windows-Rechner zwischen einerund drei Minuten dauern kann, wird für die Abwicklung der Schritte zwei bis vieraus der Abbildung ein zusätzlicher Button („Connect to TIA“) eingefügt. Damit istfür den Benutzer transparenter zu erkennen, in welchem Verarbeitungsschritt sich dasProgramm aktuell befindet. Der Button wird in der Oberfläche ausgegraut, sobald dieVerbindung zum gewünschten Projekt hergestellt ist.

47

4 Durchführung

Zur Kommunikation mit der Openness-Schnittstelle wird eine Klasse TiaHandler an-gelegt, in der Funktionen zum Öffnen und Schließen des TIA Portals und Projektendarin und natürlich zum Laden von Quellcodedateien implementiert sind. Einige Be-sonderheiten dieser Klasse sollen hervorgehoben werden:

• TIA kann von Openness mit oder ohne grafischer Benutzeroberfläche gestartetwerden. Standardmäßig öffnet GerTi TIA immer mit Benutzeroberfläche, für dieUnit-Tests wird diese aber abgeschaltet, damit bei den Tests keine zusätzlichenFenster entstehen und die Tests etwas schneller laufen.

• Vor dem Öffnen des TIA Portals kontrolliert GerTi zunächst, ob das gewünschteProjekt schon geöffnet ist. In diesem Fall wird das TIA Portal nicht neu gest-artet, sondern GerTi verbindet sich mit dem bestehenden TIA-Prozess. Diesermöglicht es, parallel mit GerTi und der geöffneten TIA-Anwendung zu ar-beiten und erspart viel Zeit, da TIA nicht ein weiteres Mal geöffnet werdenmuss.

• Sobald das TIA-Projekt geöffnet ist, kann GerTi über den Namen der darinenthaltenen CPUs erkennen, ob es sich dabei um leere CPUs handelt. Auf dieseArt und Weise kann die korrekte CPU für das Laden der Quellen identifiziertwerden.

• Für den Fall, dass das Projekt nicht geöffnet werden kann, wird eine UnableTo-OpenProjectException geworfen, damit dem Benutzer eine entsprechende Fehler-meldung angezeigt werden kann.

• Wird das TIA Portal durch den Benutzer geschlossen, so wird von Openness einDisposed-Event ausgelöst. Dieses Event wird vom TiaHandler verarbeitet undan den Controller hochgereicht, sodass in der GUI angezeigt werden kann, dasskeine Verbindung zu TIA mehr besteht. Der Button „Connect to TIA“ wirddann wieder aktiviert, sodass der Benutzer auf Wunsch das TIA Portal neuöffnen kann.

4.7 GerTi

Wie bereits oben erwähnt, ist das Projekt GerTi in die drei Teilkomponenten Model,ViewModel und View aufgeteilt. Es wird zuerst das Model, dann die ViewModelsund schließlich der View beschrieben, da der View vom ViewModel und das View-Model vom Model abhängt. Diese Abhängigkeiten sind bereits in Abbildung 6 inAbschnitt 2.6.5 angedeutet und entsprechen dem Muster MVVM. Im Architektur-diagramm auf Seite 37 kann man ebenfalls den internen Aufbau des Projects GerTierkennen.

48

4.7 GerTi

4.7.1 Model

Streng genommen, gehören nicht nur die Model-Komponenten aus dem Projekt GerTi,sondern auch die anderen Projekte – Logger, ModGen, GitUpdater und PlcImporter –zum Model dieses Programms. Damit das ViewModel die anderen Projects nicht ken-nen muss, wird mit dem Model im Paket „GerTi“ eine zusätzliche Abstraktionsschichthinzugefügt, die die Methodenaufrufe an die anderen Projects kapselt und dem View-Model zur Verfügung stellt. In dieser Abstraktionsschicht befinden sich unter anderemdie Klassen Controller und GerTiProject.

Controller

Im Controller werden einige Variablen und Objekte gespeichert, die dem gesamtenProjekt GerTi (also auch den ViewModels) zur Verfügung stehen sollen. Um denZugriff auf das Controller-Objekt zu vereinfachen und um sicherzustellen, dass je-weils nur eine Instanz des Controller-Objekts vorhanden ist, wird für diese Klas-se das Singleton-Designmuster angewendet. Da die Klasse zusätzlich ein Interface(INotifyPropertyChanged) implementieren muss, ist die Verwendung einer statischenKlasse nicht möglich. In C# kann das Singleton-Pattern sehr einfach mithilfe einesöffentlichen Properties Instance und einer privaten Backing-Store-Variablen instanceumgesetzt werden:17

1 private static Controller instance;2 public static Controller Instance =>3 instance ?? (instance = new Controller ());

Im Controller ist unter anderem die Instanz des aktuell geöffneten GerTi-Projektes (inder Variablen OpenGerTiProject) gespeichert, eine Referenz auf den TiaHandler, der denZugriff auf die TIA-Funktionen ermöglicht, und auch der Pfad des Git-Repositories,in dem die SCL-Templatedateien liegen.

Außerdem besitzt die Klasse Methoden, die Funktionsaufrufe an die anderen Projectsdes Models kapseln und von der grafischen Oberfläche aufgerufen werden können.In diesen Methoden werden zusammengehörige Funktionen ausgeführt (zum Beispieldas Generieren von allen Modulen mit dem Modul-Generator) und es werden Log-Nachrichten hinzugefügt.

17Diese Implementierung ist nicht thread-sicher, was bedeutet dass es zu Problemen kommen kann,falls mehrere Threads gleichzeitig auf die Instanz zugreifen möchten. Da im gesamten Programmnur mit dem UI-Thread gearbeitet wird, stellt dieses Verhalten kein Problem dar.

49

4 Durchführung

GerTiProject

Um die Anforderungen zum Speichern von Projektdaten umzusetzen, wird die KlasseGerTiProject angelegt, bei der es sich essentiell um eine Datenhaltungsklasse handelt.Es sind darin folgende Daten gespeichert:

• Pfad zur Excel-Datei und Pfad zum TIA-Projekt

• Maximalanzahl für die Modulaufrufe: Ventile, Motoren, Digitals, AnaIn, Ana-Out, ManualValves und für die Anzahl der Aufrufe pro Datei

• Git-Update-Kennzeichen

• Zum Löschen oder Import markierte Dateien (als Liste von Pfaden)

Es stehen in der Klasse mit SaveToDisk und ReadFromDisk Methoden zum Speichern undLaden des Projektes auf der Festplatte bereit. Beim Speichern wird XML verwendet,da dieses Format menschenlesbar ist und so die Projektdaten – falls nötig – eingesehenund von Hand editiert werden können. ReadFromDisk ist eine statische Methode, derein Dateipfad übergeben wird und die ein GerTiProject zurückgibt. Auch die MethodeSaveToDisk nimmt einen Dateipfad entgegen. Zusätzlich implementiert die Klasse füralle ihre Properties das Interface IDataErrorInfo, das im folgenden Abschnitt erläutertwird.

Input Validation mit IDataErrorInfo

Wenn eine Klasse das von Microsoft vorgegebene Interface IDataErrorInfo implemen-tiert, kann sie Fehlerzustände in ihren Properties anzeigen. Wenn diese Klasse zumBeispiel ein Feld age hat und dort ein negativer Wert eingetragen ist, kann die Klasseauf Anfrage den String Age cannot be negative zurückgeben. Um das Interface zu im-plementieren, muss die Klasse zwei Properties besitzen: Einen String Error, der eineallgemeine Fehlerinfo zu diesem Objekt enthalten kann und ein String-Array, das fürjedes Property in diesem Objekt eine Fehlermeldung enthält, falls es fehlerhaft ist.Wenn der String für ein Property null ist, bedeutet dass, dass das Property aktuellfehlerfrei ist.

In der Klasse GerTiProject ist zusätzlich zu den Properties des Interfaces eine Me-thode isValid() implementiert, die anzeigt, ob das Gesamtprojekt fehlerfrei ist odernicht.

Die grafische Oberfläche – speziell das Konfigurationsfenster – kann diese Funktio-nalität nutzen, um dem Nutzer eine Rückmeldung bei falsch eingegebenen Daten zugeben und das Speichern von fehlerhaften Daten zu verhindern.

50

4.7 GerTi

4.7.2 ViewModel

Nach der Beschreibung des Models folgt in diesem Kapitel die grafische Benutzero-berfläche.

Für GerTi werden insgesamt zwei Fenster benötigt: Ein Hauptfenster, in dem diewichtigsten Funktionalitäten des Programms untergebracht sind, und ein separatesFenster, indem die Projektdaten des aktuell geöffneten GerTiProjektes geändert wer-den können. Die Namen der beiden Fenster sind MainWindow und ConfigWindow, siewerden im Abschnitt 4.7.3 noch im Detail vorgestellt. Da in MVVM jedes Fenstereinem View entspricht und für alle Views je ein ViewModel benötigt wird, werdenzwei Klassen, das MainWindowViewModel und das ConfigWindowViewModel angelegt.

Eine besondere Herausforderung bei der Implementierung der ViewModels ist es, dar-auf zu achten, dass die ViewModels in keiner Weise von den Views abhängen. Dasbedeutet auch, dass die ViewModels nicht selbst Fenster erzeugen dürfen, zum Bei-spiel um dem Benutzer Fehlermeldungen anzuzeigen oder Datei-Dialoge zu öffnen.Diese Funktionalitäten können aber in andere Klassen ausgelagert werden, die zurLaufzeit ausgetauscht werden können.

Für alle Daten, die in den Views dargestellt werden sollen, werden in den ViewModelsöffentliche Properties angelegt. Soll zum Beispiel ein Textfeld angezeigt werden, indas der Benutzer Daten eintragen kann, wird im ViewModel des Fensters ein Stringangelegt, auf den der View zugreifen darf. Mit einem Binding, also einer Datenbindung,werden im View Textfeld und String verknüpft. Je nach Modus des Bindings kanndie Schreib-Richtung der Daten festgelegt werden: Mode=OneWay erlaubt es dem Viewbeispielsweise nicht, die Daten im ViewModel zu verändern während Änderungen,die vom ViewModel ausgehen, möglich sind (Natürlich können im View durch einenprivaten Setter Änderungen durch andere Objekte pauschal ausgeschlossen werden).

INotifyPropertyChanged

Damit die Views aktualisiert werden, wenn sich eines der Properties im ViewModeländert, muss das ViewModel das Interface INotifyPropertyChanged implementieren.Das Interface enthält lediglich ein Ereignis, das Event PropertyChanged, das von ande-ren Objekten abonniert werden kann, wenn diese über Änderungen an den Propertiesinformiert werden möchten. Da beim Auslösen des Events Argumente übergeben wer-den sollen und vor dem Aufruf stets überprüft werden muss, ob das Event null ist,bietet es sich an, für die Überprüfungen eine zusätzliche Methode anzulegen, die vonden Properties im Setter aufgerufen werden kann. Da die Interface-Implementierungeine Gemeinsamkeit aller ViewModels ist, wird sie in eine gemeinsame Basisklasse,die ViewModelBase, ausgelagert (siehe Listing 19).

51

4 Durchführung

1 public abstract class ViewModelBase: INotifyPropertyChanged {2 // Required by INotifyPropertyChanged3 public event PropertyChangedEventHandler PropertyChanged;4

5 // Wrapper for invocation of PropertyChangedEvent6 public void OnPropertyChanged(7 [CallerMemberName] string propertyName = "") {8 PropertyChanged ?. Invoke(this ,9 new PropertyChangedEventArgs(propertyName));

10 }11 }

Listing 19: ViewModel-Basisklasse ViewModelBase

Das Attribut [CallerMemberName], das in dieser Implementierung der Methode On-PropertyChanged() verwendet wird, ermöglicht es, den Namen des Properties, das dieMethode aufruft, mit zu übergeben, ohne diesen explizit in den Methodenaufruf zuschreiben (vgl. [3]). Dies ermöglicht den Aufruf von OnPropertyChanged() wie er imListing 20 dargestellt ist. Bei diesem Listing handelt es sich um einen Ausschnitt derKlasse MainWindowViewModel.

1 private string inputFile;2 public string InputFile {3 get { return inputFile; }4 set {5 if (value == inputFile)6 return;7 inputFile = value;8 OnPropertyChanged ();9 }

10 }

Listing 20: Aufruf des PropertyChanged-Events

Ein besonderer Vorteil dieses Interfaces ist es, dass die ViewModels unabhängig vonden Views bleiben und diese nicht kennen müssen. Objekte wie die Views können sicheinfach beim ViewModel als EventListener registrieren und werden auf diese Art undWeise über Änderungen informiert.

Auch die Klassen Controller und GerTiProject aus dem Datenmodell implementierenINotifyPropertyChanged. In diesem Fall geht es allerdings nicht darum, Datenänderun-gen an die Views weiterzureichen, sondern erst einmal darum, die Änderungen an dasViewModel zu geben.

52

4.7 GerTi

Commands

Mit den WPF-Commands soll an dieser Stelle noch eine weitere Technik erläutertwerden, die von den ViewModels eingesetzt wird, um die Struktur des Programms zuverbessern und die Einhaltung von MVVM zu gewährleisten. Um Commands umzu-setzen, gibt es das Interface ICommand, das zwei Methoden, CanExecute() und Execute()sowie ein Event CanExecuteChanged enthält. Typische Beispiele für Commands sind dieKopiere- und Einfüge-Operationen in Textfeldern. Beim Ausführen des Commands(zum Beispiel durch einen Button oder eine Tastenkombination) wird eine Aktionausgelöst, indem die Execute-Methode des Commands aufgerufen wird. Ob das Com-mand überhaupt ausführbar ist, kann über die Methode CanExecute abgefragt werden(„Kopieren“ kann zum Beispiel nur dann ausgeführt werden, wenn auch Text markiertist).

Bestimmte grafische UI-Elemente (zum Beispiel Buttons oder Menüeinträge) kön-nen mit einem Binding im View an ein Command gebunden werden. Ein Klick aufden Button oder Menüeintrag führt dann dazu, dass das Command ausgeführt wird.Die Verwendung von Commands ist gewöhnlichen „OnClickHandlern“ deutlich über-legen: Beim einem Command wird der daran gebundene Button ausgegraut, wenndas Command aktuell nicht ausführbar ist, wenn also die CanExecute-Methode falsezurückgibt.

Aus diesem Grund werden für die Befehlsübermittlung von der GUI an die ViewMo-dels Command-Objekte verwendet. Diese können gut als Klassenvariable im jeweiligenViewModel hinterlegt werden. Damit nicht für jedes neue Command eine neue Klasseangelegt werden muss, wird ein sogenanntes RelayCommand verwendet. Dabei handelt essich um eine Klasse, die ICommand implementiert, aber alle Methodenaufrufe der Me-thoden Execute und CanExecute an ein Delegate weiterleitet. Das Delegate kann dannauf eine Methode im ViewModel zeigen. Eine leicht vereinfachte Version des in GerTiverwendeten RelayCommands ist in Listing 21 dargestellt.

1 public class RelayCommand : ICommand {2 private readonly Action <object > execute;3 private readonly Predicate <object > canExecute;4

5 public RelayCommand(Action <object > execute ,6 Predicate <object > canExecute) {7 this.execute = execute;8 this.canExecute = canExecute;9 }

10

11 public bool CanExecute(object o) {12 canExecute(o);13 }14

53

4 Durchführung

15 public void Execute(object o) {16 execute(o);17 }18

19 public event EventHandler CanExecuteChanged;20 }

Listing 21: Klasse RelayCommand (vereinfacht)

Listing 22 zeigt die Anwendung des RelayCommands im Code, so wie es auch imMainWindowViewModel und im ConfigWindowViewModel verwendet wird. Als Bei-spiel wurde das HelpCommand ausgewählt, da es eine sehr einfache CanExecute-Logikbesitzt – es ist immer ausführbar.

1 public RelayCommand HelpCommand { get; private set; }2

3 private void InitializeCommand () {4 HelpCommand = new RelayCommand(HelpExecute , x => true);5 // Initialization of other commands ...6 }7

8 private void HelpExecute(object e) {9 // Show help window ...

10 }

Listing 22: Verwendung des RelayCommands im ViewModel

Die Methode InitializeCommands() wird im Konstruktor des ViewModels aufgerufen,um alle Command-Objekte zu initialisieren. HelpExecute() wird als Execute-Methodedes RelayCommands gesetzt (siehe Zeile 4). Das führt dazu, dass die Methode beimAusführen des RelayCommands aufgerufen wird. Analog gibt es in den ViewModelsfür die anderen Commands weitere Methoden, die mit den Execute-Methoden der Re-layCommands verknüpft werden. Die Methodensignatur aller dieser Methoden mussdem im RelayCommand vorgegebenen Delegate Action entsprechen, dieses verlangteine void-Methode, der als Parameter ein object übergeben wird (siehe Zeile 8).

Man kann in Zeile 4 erkennen, dass anstelle einer vollständigen CanExecute-Methodeein Lambda-Ausdruck gewählt wird. Dies ist – sofern möglich – auch bei den ande-ren Commands der Fall. Analog zum Delegate für die Execute-Methode muss auchder Lambda-Ausdruck einer bestimmten Methodensignatur entsprechen – hier ist siedurch das Delegate Predicate vorgegeben.

Da von überall aus dem Programm heraus auf den Controller zugegriffen werdenkann, kann zum Beispiel in den Lambda-Ausdrücken mit Controller.Instance.Open-GerTiProject == null überprüft werden, ob aktuell ein GerTi-Projekt geöffnet ist. In

54

4.7 GerTi

den Execute-Methoden wird bei längeren Operationen zudem zunächst der Mauszeigerim Programm auf „Waiting“ gestellt, wodurch der Mauszeiger innerhalb der GerTi-Fenster durch einen Wartekringel ausgetauscht wird. Nachdem die Operation beendetist, wird der Zeiger zurückgesetzt. Dieses Verhalten wird im Listing 23 anhand derMethode StartTiaExecute gezeigt.

1 private void StartTiaExecute(object e) {2 Mouse.OverrideCursor = Cursors.Wait;3 // Start TIA Portal and handle exceptions4 Mouse.OverrideCursor = null;5 }

Listing 23: Wartezeiger bei längeren Operationen im ViewModel

Die Verwendung der Delegates im RelayCommand hat drei Vorteile gegenüber der Ver-wendung von verschiedenen Klassen, die ICommand implementieren: Erstens können dieMethoden der Commands ohne Weiteres auf private Klassenvariablen im ViewModelzugreifen, weil sie Bestandteil des ViewModles sind, was bei externen Objekten nichtso einfach möglich wäre. Zweitens können bei sehr einfachen CanExecute-MethodenLambda-Ausdrücke verwendet werden, die den Code kürzer und übersichtlicher ma-chen, und drittens können zwei verschiedene Commands die gleiche CanExecute- oderExecute-Methode besitzen ohne dass Code dupliziert werden muss, indem die Delega-tes von zwei verschiedenen Commands auf die gleiche Methode verweisen.

Nach der allgemeinen Beschreibung der ViewModels werden in den nachfolgendenzwei Abschnitten Besonderheiten des MainWindowViewModels und des ConfigWin-dowViewModels hervorgehoben.

MainWindowViewModel

Im MainWindowViewModel sind verschiedene Properties vorhanden, die durch das dazu-gehörige Fenster abgefragt werden können:

• Der Dateipfad des Excel-Dokuments und des TIA-Projektes. Eine Besonderheithier ist, dass es im MainWindowViewModel einen PropertyChangedEventHandler für dasaktuell geöffnete GerTiProject im Controller gibt, und bei Änderungen an diesemProjekt die Properties im ViewModel aktualisiert werden. Da die Propertiesselbst auch wieder PropertyChanged-Events bei Veränderungen feuern, kann derView immer den aktuellen Stand widerspiegeln.

• Pro Button in der GUI ein RelayCommand. Alle Commands des MainWindowView-Models sind in der Tabelle 1 auf Seite 57 aufgeführt.

55

4 Durchführung

• Eine ObservableCollection18, in alle die Lognachrichten abgelegt werden, damitdiese im View angezeigt werden können. Bei Änderungen an der Collection wer-den die Views entsprechend aktualisiert, sodass im ViewModel nur Programm-logik implementiert werden muss, die bei Veränderungen an den Log-Listen dieneuen Nachrichten in die Collection einfügt. Dies kann umgesetzt werden, weildas ViewModel einen eigenen ListLogger hat und dieser das Interface INotify-PropertyChanged implementiert. Wenn neue Lognachrichten in den Logger ein-gefügt werden, werden PropertyChanged-Events gefeuert, für die das ViewModelals Listener registriert ist.

• Eine weitere ObservableCollection für die Liste der bereits generierten SCL-Dateien, die im Ordner Generated liegen. Da sich die Implementierung diesesFeatures als komplex herausgestellt hat, ist ihm ein eigener Abschnitt, Kapi-tel 4.7.4, gewidmet.

Im MainWindowViewModel sind zusätzlich zu den Properties noch Klassenvariablenenthalten, die sich mit der Erzeugung von neuen Fenstern beschäftigen. Dazu ge-hört eine IWindowFactory, eine Schnittstelle, die die Funktion CreateNewConfigWindow()enthält. Diese erzeugt per new ConfigWindow() ein neues Fenster.

Eine zweite Klassenvariable, ein IExceptionHandler, besitzt eine Methode public voidHandle(Exception e), die für eine gegebene Exception eine für den Nutzer passendeFehlermeldung ausgibt. Auch hierbei wird ein Fenster erzeugt, in diesem Fall handeltes sich um eine einfache MessageBox. Damit alle Exceptions, die beim Aufruf von Model-Funktionen entstehen können, auch von dem Handler verarbeitet werden können,werden die Aufrufe in den Execute-Methoden im ViewModel stets in try-catch-Blöckenausgeführt.

Da diese Variablen im Konstruktor des MainWindowViewModels übergeben werdenmüssen, ist es sehr einfach möglich, ViewModels zu erstellen, die keine Fenster erzeu-gen, indem entsprechend andere Variablen gewählt werden, die ebenfalls die Schnitt-stellen IWindowFactory beziehungsweise IExceptionHandler implementieren. Dieses Ver-halten ist unter anderem für die UnitTests sehr nützlich.

ConfigWindowViewModel

Im Konfigurationsfenster sollen die Projektdaten des aktuellen GerTi-Projektes ge-ändert werden können. Dabei wird das Fenster sowohl für neu angelegte Projekte zurErstkonfiguration als auch für bestehende Projekte zur nachträglichen Änderung von

18Diese Klasse ist im Namespace System.Collections.ObjectModel zu finden und bildet eine Col-lection, die bei Änderungen an den enthaltenen Objekten Events feuert, um andere Objekte zubenachrichtigen.

56

4.7 GerTi

Tab. 1: Commands im MainWindowViewModel

Name Funktion Ausführbar

NewProject Anlegen eines neuen Projek-tes

wenn kein Projekt offen

OpenProject Öffnen eines Projektes wenn kein Projekt offen

CloseProject Schließen eines Projektes wenn ein Projekt geöffnet ist

Settings Einstellungsfenster des Pro-jektes öffnen

wenn ein Projekt geöffnet ist

Update Update der Vorlagen aus-führen

wenn ein Projekt geöffnet istund das Update für diesesProjekt nicht abgeschaltet ist

Help Hilfefenster öffnen immer

Generate Quellcode generieren wenn ein Projekt geöffnet ist

Delete Markierte Dateien löschen wenn Dateien markiert sind

StartTia TIA Portal und TIA-Projekt öffnen

wenn TIA nicht bereits geöff-net ist

ImportAndCompile Markierte Dateien impor-tieren und übersetzen

wenn Dateien markiert sind

57

4 Durchführung

Daten verwendet. Im ConfigWindowViewModel werden daher Properties angelegt, die al-le benötigten Daten aus dem GerTi-Projekt abbilden, also zum Beispiel Strings fürDateipfade und Integer für Maximalwerte. (Alternativ wäre es natürlich möglich imConfigWindowViewModel ein Property vom Typ GerTiProject anzulegen, aus dem derView die Daten beziehen könnte. Das würde allerdings dazu führen, dass der View di-rekt auf Klassen aus dem Model zugreifen müsste und würde einen Bruch mit MVVMbedeuten.)

Auch diese Klasse besitzt einige Relay-Commands zum Ausführen von Aktionen (sieheTabelle 2).

Tab. 2: Commands im ConfigWindowViewModel

Name Funktion Ausführbar

Save Speichern und Schließen desFensters

wenn Projektdaten gültig

BrowseInputFile Explorer-Dialog für Excel-Datei öffnen

immer

BrowsePlcFile Explorer-Dialog für TIA-Datei öffnen

immer

Ein Cancel-Command, mit dem das Fenster geschlossen werden kann ohne zu spei-chern, wird nicht benötigt, da hier vom View aus eine eingebaute Funktionalität vonWPF zum Abbrechen von Aktionen verwendet werden kann.

Damit die Daten erst dann in das aktuell geöffnete Projekt übernommen werden,wenn der Benutzer die Änderungen mit Save bestätigt, arbeitet das ViewModel miteiner Kopie des aktuell geöffneten Projektes. Dazu erhält die Klasse GerTiProjecteine Clone()-Methode, die eine Deep-Copy19 des Projektes zurückgibt. Das Speichern-Command ist nur dann ausführbar wenn diese Kopie fehlerfrei ist, wenn also dieIsValid()-Methode des Projektes true zurückgibt. Beim Speichern wird das Projektautomatisch auch auf der Festplatte abgelegt.

19Bei einer Deep-Copy werden von allen Referenzen, die ein Objekt besitzt, ebenfalls Kopien ange-legt.

58

4.7 GerTi

Die Properties im ConfigWindowViewModel implementieren IDataErrorInfo, könnenalso anzeigen, wenn sie fehlerhafte Daten enthalten. Das kann vom View genutztwerden, um dem Nutzer zu zeigen, welche Daten fehlerhaft sind.

4.7.3 View

MainWindow

Das Hauptfenster von GerTi direkt nach dem Programmstart ist auf Abbildung 19zu erkennen. Es ist in vier verschiedene Bereiche unterteilt, die auf der Abbildungeingezeichnet sind:

1. Buttonleiste mit Projektfunktionen

Hier finden sich allgemeine Funktionen wie das Öffnen/Schließen von Projekten,das Ändern von Projektdaten oder das Update der Vorlagendateien. Zusätzlichist hier ein „Hilfe“-Knopf und das GEA-Logo untergebracht.

2. Gruppe zur Modulgenerierung

In diesem Bereich wird der Name der Excel-Datei angezeigt, die als Grundla-ge für die SCL-Generierung dient. Ein zusätzlicher Button „Generate“ in derrechten unteren Ecke stößt die Quellcodegenerierung an.

3. Gruppe für den TIA-Import

Im Bereich „Import Modules into TIA“ wird der Dateipfad zum TIA-Projekt undeine Liste der Dateien angezeigt, die importiert werden können. Über CheckBo-xen neben dem Dateinamen können die Dateien ausgewählt werden. Der Button„Delete Modules“ löscht alle markierten Dateien, der Button „Connect to TIA“startet das TIA Portal und öffnet das angegebene Projekt und der Button „Im-port and Compile“ lädt alle markierten Dateien in das Projekt und kompiliertdiese.

4. Loggingfenster für Statusinformationen

In der Loggingkonsole werden alle Lognachrichten mit Zeitstempel und LogLevelangezeigt, die zur Laufzeit des Programms entstanden sind. Neue Nachrichtenwerden dabei oben in der Konsole angezeigt.

Der XAML-Code des MainWindows befindet sich in der Datei MainWindow.xaml. Umdie vier Bereiche zu erzeugen, wird das Containerelement <Grid> verwendet, das seineKindelemente in einer Tabelle darstellt. Das Grid hat fünf Zeilen und eine Spalte.Die fünfte Zeile ergibt sich dadurch, dass zwischen dem dritten und vierten Bereichein <GridSplitter> eingebaut ist, der es ermöglicht, die Höhe des dritten Bereiches

59

4 Durchführung

Abb. 19: Hauptfenster der Anwendung GerTi beim Start

zu verkleinern und die des Vierten zu vergrößern. Auch eine Vergrößerung des Ge-samtfensters ist möglich – hier werden alle Bereiche verbreitert und der dritte wirdzusätzlich in der Höhe verändert, sodass mehr von der Dateiliste in diesem Bereichzu erkennen ist. Für die veränderten Fenstergrößen finden sich Screenshots der An-wendung in Anhang A.4 beziehungsweise Anhang A.3.

Sämtliche Buttons des Fensters enthalten ein StackPanel, in dem ein Textfeld und einBild untergebracht sind. Durch ein Binding an ein Command-Objekt werden Klicks aufden Button an das ViewModel weitergeleitet. Listing 24 zeigt ein Beispiel für einenButton im MainWindow.

1 <Button Command="{Binding OpenProjectCommand}" MinWidth="80"

60

4.7 GerTi

2 Padding="3">3 <StackPanel >4 <Image Source="/GerTi;component/Images/add -1. png"5 Height="24" Width="24" />6 <TextBlock Text="New" />7 </StackPanel >8 </Button >

Listing 24: Button mit Command-Binding im MainWindow

In der Code-Behind-Datei des Views wird ein neues Objekt vom Typ MainWindowViewModel erzeugt und als Datenkontext des MainWindow gesetzt (siehe Listing 25). Dadas MainWindow in der Datei App.xaml als Start-Fenster der Anwendung angegebenist, wird dieser Konstruktor beim Programmstart aufgerufen und das Fenster wirdangezeigt.

1 public partial class MainWindow : Window2 {3 public MainWindow () {4 DataContext = new MainWindowViewModel(5 new ConfigWindowFactory (),6 new GuiExceptionHandler (),7 new DialogFileChooser));8 InitializeComponent ();9 }

10 }

Listing 25: Code-Behind des MainWindows (MainWindow.xaml.cs)

ConfigWindow

Im Konfigurationsfenster sollen die Daten des GerTiProjektes angezeigt und verändertwerden können. Um das Fenster besser zu strukturieren, werden die Daten in dreiverschiedene Tabs (Reiter) aufgeteilt: einen für allgemeine Informationen, einen fürdie Maximalwerte bei zu generierenden Modulen und einen für Einstellungen beimUpdate der Vorlagendateien. Die Tabs werden XAML-seitig mithilfe einer TabControlumgesetzt. Innerhalb dieses Elements gibt es verschiedene TabItems (siehe Listing 26),in denen jeweils ein Grid für die darin enthaltenen Elemente zu finden ist.

1 <TabControl Margin="5">2 <TabItem Header="General">3 <!-- Content -->4 </TabItem >

61

4 Durchführung

5 <!-- More TabItems ... -->6 </TabControl >

Listing 26: TabControl im ConfigWindow

Neben den Tabs ist im ConfigWindow noch die Eingabevalidierung hervorzuheben.Da die Properties im ConfigWindowViewModel das Interface IDataErrorInfo unter-stützen, kann der View abfragen, ob die Werte aktuell Fehler enthalten:

1 <TextBox Text="{Binding Path=InputFile ,2 ValidatesOnDataErrors=True ,3 UpdateSourceTrigger=PropertyChanged}" />

Im Fehlerfall wird dann das Textfeld mit den Eingabedaten mit einem roten Randversehen (siehe Abbildung 20). Durch das Attribut UpdateSourceTrigger kann einge-stellt werden, wie häufig der Wert validiert wird. In diesem Fall wird immer dannvalidiert, wenn sich der Wert im Textfeld geändert hat. Bei sehr komplexen Validie-rungsroutinen kann der der Trigger auch auf LostFocus gestellt werden. Dann wird dasFeld nur validiert, wenn der Tastatur-Fokus wechselt, also in ein anderes Feld gesetztwird, wodurch Ressourcen gespart werden.

Auf der Abbildung kann man auch erkennen, dass der „Save“-Button deaktiviert ist,das Projekt also in diesem Zustand nicht gespeichert werden kann. Dies wird erreicht,indem im ConfigWindowViewModel für das SaveCommand in der CanExecute-Methode abge-fragt wird, ob das GerTiProject im Konfigurationsfenster gültig ist und keine Fehleraufweist. Dafür besitzt jedes GerTiProject die Methode IsValid().

Weitere Screenshots des Konfigurationsfensters finden sich im Anhang A.

Abb. 20: InputValidation im ConfigWindow

62

4.7 GerTi

4.7.4 Liste der generierten Dateien in der GUI

Um alle generierten Dateien in der GUI anzuzeigen, wird im MainWindowViewModeleine generische ObservableCollection angelegt, die SourceFileList heißt und in der dieQuelldateien gespeichert sind. Zur Repräsentation der Quelldateien wird eine KlasseSourceFile im Model angelegt, die einen Dateinamen und einen bool IsChecked enthält,der widerspiegelt, ob die Datei ausgewählt ist oder nicht. Für den Boolean implemen-tiert die Klasse das Interface INotifyPropertyChanged, das heißt immer dann wenn derWert IsChecked verändert wird, wird ein PropertyChangedEvent gefeuert.

Ein vereinfachtes Klassendiagramm mit diesen beiden Properties und weiteren rele-vanten Funktionen ist in Abbildung 21 dargestellt.

Abb. 21: Vereinfachtes Klassendiagramm für die Anzeige der Quelldateien in der GUI

Das MainWindow bezieht die anzuzeigenden Daten aus der SourceFileList. Für jededarin enthaltene Datei wird der Dateiname neben einer CheckBox angezeigt. Da dieElemente in der Liste mit den eigentlichen SourceFiles verbunden sind, wird beimAuswählen einer der CheckBoxen auch das dazugehörige SourceFile verändert.

Außerdem existiert eine zentrale CheckBox im MainWindow, über die alle Datei-en gleichzeitig ausgewählt werden können. Für diese CheckBox gibt es im Main-WindowViewModel ein weiteres Property, SourceFilesCheckBox, das den Zustand derCheckBox darstellt. Da es sich um eine „Three-State-CheckBox“ handelt, die miteinem ausgefüllten Quadrat anzeigen kann, wenn mindestens eine, aber nicht alle Da-teien ausgewählt sind, wird als Typ des Properties bool?20 gewählt. Beim Klick derCheckBox werden im Setter im ViewModel die IsChecked-Werte aller SourceFiles inder Dateiliste auf den passenden Wert gesetzt. Die SourceFilesCheckBox ist ebenfallsin Abbildung 21 zu finden.

20Das Fragezeichen gibt in C# an, dass ein Wert „nullable“ ist, also null werden darf.

63

4 Durchführung

Die Methode RefreshSourceFiles() baut die Liste der Dateien neu auf, wenn sichdas aktuelle Projekt oder Inhalte des Ordners „Generated“ geändert haben können.Quellcodedateien, die im aktuellen GerTiProject bereits vorhanden sind, werden miteinem Häkchen vorbelegt. RefreshSourceFiles() ruft auch die Methode UpdateSource-FilesCheckBox() auf, die den Wert der zentralen CheckBox setzt.

Damit bei den Änderungen an den SourceFiles weitere Aktionen ausgeführt werdenkönnen, wird ein EventHandler für die PropertyChangedEvents der SourceFiles benö-tigt, der bei neuen SourceFiles eingehängt wird und wieder entfernt wird, wenn dasSourceFile nicht mehr benötigt wird21. Im EventHandler werden die Änderungen ander Liste an das aktuell geöffnete GerTiProject weitergegeben.

Beim Klick einer der CheckBoxen in der GUI ergibt sich der in Abbildung 22 darge-stellte Ablauf.

KlickCheckBox

Änderungam

SourceFile

Changed-Event-Handler

GerTi-Projectändern

UpdatezentraleCheckBox

Abb. 22: Ablauf beim Klick einer Datei-CheckBox in der GUI

21Wird der EventHandler nicht entfernt, obwohl das Objekt nicht mehr benötigt wird, kommt es zuSpeicherlecks, da das Objekt vom GarbageCollector noch nicht abgeräumt werden darf.

64

5 Tests

Für die gesamte Software werden während der Entwicklungsphase UnitTests in Micro-softs UnitTesting-Framework geschrieben, damit die Funktionsfähigkeit der Einzel-komponenten möglichst früh überprüft werden kann. Zusätzlich dazu werden durchTester und Anwender manuelle Tests durchgeführt, mit denen sichergestellt werdensoll, dass die Software (insbesondere die grafische Oberfläche) gut bedienbar ist unddie Kommunikation mit dem TIA Portal erwartungsgemäß funktioniert. In diesem Ka-pitel werden zunächst die UnitTests allgemein erläutert, bevor auf die Besonderheitenbeim Test mit Jenkins und bei den UnitTests der ViewModels und dem TIA Importeingegangen wird. Zum Schluss werden die manuellen Tests erörtert.

5.1 UnitTests

Die UnitTests können automatisch in einem Testlauf im Visual Studio und auch aufdem Jenkins-Server ausgeführt werden. Um die Tests besser zu strukturieren, wirdfür jedes Project in der Solution ein entsprechendes Test-Project angelegt, wobei dasProject „GerTiTests“ in zwei Projects aufgeteilt wird, damit mit Jenkins getestetwerden kann (siehe Abschnitt 5.1.1).

Insgesamt werden 108 UnitTests in sechs verschiedenen Projekten implementiert, diezusammengefasst über 1600 Codezeilen enthalten. Abbildung 23 zeigt einen Test-durchlauf von ReSharper, in dem man sehen kann, dass alle Tests erfolgreich sind.Links neben dem Testergbnis ist die Dauer des Testdurchlaufs für jedes Project an-gegeben. Man kann erkennen, dass die TIA-Tests durch den mehrfachen Start desTIA Portals den größten Zeitaufwand darstellen.

Abb. 23: Ermittlung der Testergebnisse nach Project mit ReSharper

ReSharper kann sowohl die UnitTests ausführen, als auch deren Testabdeckung er-mitteln und sogar im Quellcode anzeigen, welche Zeilen des Programms durchlaufenwerden und welche nicht. Bei der Ermittlung der Testabdeckung sollen Fremdkompo-nenten ausgelassen werden, die die Testergebnisse verfälschen würden. Dazu gehört

65

5 Tests

beispielsweise die Datei Annotations.cs, die von ReSharper neu definierte Annota-tions enthält, in der sich allerdings kein eigener User-Code befindet. Der XAML-Code wird nicht automatisiert, sondern manuell getestet, und soll ebenfalls nicht mitin die Testabdeckung einfließen. Bei Fertigstellung des Projektes liegt die Gesamt-Testabdeckung bei 94%.

Die Aufteilung der Testabdeckung auf die einzelnen Projekte wird auf Abbildung 24ersichtlich. Der große Teil der fehlenden Zeilen im Project GerTi entsteht dadurch,dass sich hier einige Methoden befinden, die Fenster erzeugen und daher bewusstnicht getestet werden. Lässt man die dazugehörigen Klassen in der Betrachtung derTestabdeckung weg, so steigt die Abdeckung auf 98%.

Abb. 24: Ermittlung der Testabdeckung mit ReSharper

Trotz der hohen Testabdeckung ist davon auszugehen, dass nicht alle Fehlerfälle vonden Tests erreicht werden können. Da es in C# keine checked Exceptions gibt, alsoExceptions, die in der Methodensignatur angekündigt werden und eine eine möglicheBehandlung schon durch den Compiler erzwingen, könnten in Fremdcode Exceptionsentstehen, mit denen zur Entwicklungszeit nicht gerechnet wird. Diese werden zwarim ViewModel durch den ExceptionHandler abgefangen, es kann dann aber keine guteRückmeldung an den Benutzer gegeben werden, wie der Fehler entstanden ist. Damitkeine Fehler übersehen werden, werden in den manuellen Tests zusätzlich diverseFehlerfälle überprüft.

Da viele der Projects auf Dateien auf der Festplatte zugreifen müssen, wird bei denTests auf eine Abstraktion des Dateisystems verzichtet. Damit die UnitTests kei-ne ungewünschten Nebeneffekte hervorrufen, werden sie stets in einem gesondertenTest-Ordner ausgeführt, der vom UnitTesting-Framework automatisch bei jedem Test-lauf angelegt wird. Neue, von den Tests erstellte, Dateien werden dann ausschließlichin diesem Ordner abgelegt. Interferenzen innerhalb verschiedener Tests werden aus-geschlossen, indem vor oder nach einem Testlauf angelegte Dateien wieder gelöschtwerden.

Die Testressourcen, also für den Test benötigte Dateien, wie zum Beispiel Excel-Dokumente oder TIA-Projekte, werden als Eingebettete Ressource in das Visual Stu-dio-Projekt eingetragen. Durch die Angabe des Attributes DeploymentItem kann dasUnitTesting-Framework dazu angewiesen werden, Test-Ressourcen in den Testordner

66

5.1 UnitTests

zu kopieren. Optional kann noch ein alternativer Dateipfad angegeben werden. DieAnnotation wird wie folgt an eine Testklasse angefügt:

1 [TestClass]2 [DeploymentItem(@"res\scl\Valves.scltemplate", @"Templates")]3 [DeploymentItem(@"res\ExcelHandlerDataTest.xlsx")]4 public class ModGenTests5 {6 // ...7 }

Listing 28: Angabe eines DeploymentItems in den UnitTests (gekürzt)

Im Code kann dann unter Angabe des neu gewählten Dateipfades auf die Dateienzugegriffen werden. Es handelt sich bei den Testdateien um speziell für die Testsmodifizierte Excel-Tabellen und TIA-Projekte sowie neu angelegte Vorlagendateien.Bei der Erstellung muss darauf geachtet werden, dass die Daten zusammenpassen, alsozum Beispiel dass in den SCL-Vorlagen auftretende Variablen oder Datentypen auchtatsächlich im TIA Projekt vorhanden sind. Gleichzeitig dürfen die Dateien nicht zugroß werden, um die Tests zu beschleunigen und Speicherplatz im Git-Repository zusparen. Während dies bei den Vorlagen und den Excel-Dateien einfach umzusetzen ist,können TIA-Projekte leicht dutzende Megabyte belegen. Im Projekt nicht benötigteController, Bausteine und Skripte sowie die HMIs werden daher entfernt.

5.1.1 Jenkins

Die UnitTests werden von Jenkins nach jedem neuen Commit automatisiert ausge-führt. Dabei müssen einige Einschränkungen beachtet werden, denn auf dem Jenkins-Server ist das TIA Portal nicht installiert und es können keine automatischen Unit-Tests der Git-Komponenten durchgeführt werden, da hierfür aus dem Test heraus eineNetzwerkverbindung zum Git-Server hergestellt werden müsste. Aus diesem Grundwerden die Projects PlcImporterTests und GitUpdaterTests aus den UnitTests aufdem Jenkins-Server ausgeschlossen und das Project GerTiTests wird in zwei Projectsaufgeteilt – eins, in dem TIA-Komponenten und Git-Komponenten enthalten sind,und eins, in dem diese nicht vorhanden sind. Nur das zweite Project wird von Jenkinsgetestet.

Schlägt mindestens einer der Tests fehl, so wird der Build von Jenkins als „instabil“betrachtet und die Entwickler werden per E-Mail über den Fehlschlag informiert.Dieses Verhalten ist von Vorteil, da ein versehentliches Vergessen der Testdurchläufedurch die Entwickler ausgeschlossen wird.

67

5 Tests

5.1.2 ViewModels

Da die ViewModels nicht auf die Views angewiesen sind, ist es möglich, die ViewMo-dels vollständig zu testen, ohne dass während der Tests Fenster entstehen oder User-Interaktionen nötig sind. Da allerdings in den Konstruktoren der ViewModels be-stimmte Interfaces mitgegeben werden müssen, die Fenster erzeugen können, müssenfür die Tests Dummy-Klassen geschrieben werden, die diese Interfaces implementie-ren, ohne Fenster zu erstellen. Die Konstruktoren des MainWindowViewModels unddes ConfigWindowViewModels sind im folgenden Listing angegeben:

1 // Constructor MainWindowViewModel2 public MainWindowViewModel(3 IExceptionHandler exceptionHandler ,4 IFileChooser fileChooser ,5 IWindowFactory configWindowFactory);6

7 // Constructor ConfigWindowViewModel8 public ConfigWindowViewModel(9 IExceptionHandler exceptionHandler ,

10 IFileChooser fileChooser);

Listing 29: Konstruktoren der beiden ViewModels

Listing 30 zeigt die Implementierung einer Dummy-Klasse am Beispiel des IExceptionHandlers. Der Dummy-Handler hält lediglich nach, wie oft die Methode Handle auf-gerufen wird und reicht übergebene Exceptions an den aufrufenden UnitTest hoch,wo zum Beispiel mit dem Test-Attribut ExpectedException überprüft werden kann,ob vom ViewModel die richtige Exception angelegt wurde. Auf diese Art und Wei-se kann sichergestellt werden, dass das Verhalten des ViewModels im Bezug auf dieDummy-Klassen korrekt ist und die Methoden auch aufgerufen werden. Die Dummy-Klassen für die IWindowFactory und den IFileChooser sehen ähnlich aus. Dummy-Klassen werden auch in anderen Projects verwendet, zum Beispiel beim Test derKlasse LoggingService, bei dem Dummy-Logger verwendet werden, die keine Festplat-tenzugriffe verursachen.

1 public class DummyExceptionHandler : IExceptionHandler {2 // Count how many times Handle () is called3 public int Handled;4 public void Handle(Exception ex) {5 Handled ++;6 throw ex;7 }8 }

68

5.1 UnitTests

Listing 30: Dummy-Klasse für IExceptionHandler

Nach Erzeugung der Dummy-Objekte können die öffentlichen Methoden der ViewMo-dels getestet werden. Da die Command-Objekte öffentliche Properties in den View-Models sind, können nicht nur die Views, sondern auch die UnitTests auf sie zugreifenund die Execute und CanExecute-Methoden ausführen. Listing 31 zeigt diesen Test an-hand des Settings-Commands, das aufgerufen wird, um ein Fenster zum Bearbeitender Projektinformationen zu öffnen. Man kann erkennen, dass das Command nurdann ausgeführt werden kann, wenn ein GerTi-Projekt geöffnet ist. Da das Speichernder neuen Informationen über ein weiteres Command im ConfigWindowViewModelausgelöst wird, wird es in diesem Test nicht mit abgedeckt.

1 [TestMethod]2 public void SettingsExecuteTest () {3 // Create new MainWindowViewModel with dummy classes4 DummyWindowFactory wf = new DummyWindowFactory ();5 DummyExceptionHandler eh = new DummyExceptionHandler ();6 DummyFileChooser fc = new DummyFileChooser ();7 MainWindowViewModel vm = new MainWindowViewModel(wf, eh , fc);8

9 // Test CanExceute10 Assert.IsFalse(vm.SettingsCommand.CanExecute(null));11 Controller.Instance.OpenGerTiProject = new GerTiProject ();12 Assert.IsTrue(vm.SettingsCommand.CanExecute(null));13

14 // Test Exceute15 Assert.AreEqual(0, wf.NewWindowCalls);16 vm.SettingsCommand.Execute(null);17 Assert.AreEqual(1, wf.NewWindowCalls);18 }

Listing 31: Test des Settings-Command im MainWindowViewModel (vereinfacht)

5.1.3 TIA

Versucht sich ein externes Programm (wie zum Beispiel GerTi) mit dem TIA Portalzu verbinden, so wird in TIA eine Sicherheitsmeldung angezeigt, durch die sicherge-stellt werden soll, dass die externe Anwendung auch tatsächlich auf TIA zugreifendarf. Diese Meldung muss durch den User bestätigt werden. Zwar gibt es eine Mög-lichkeit, der Anwendung dauerhaft Zugriff zu gewähren, sodass das Fenster nicht mehrerscheint, allerdings werden von TIA zwei verschiedene Versionen derselben Anwen-dung schon als zwei verschiedene Programme betrachtet. Das führt dazu, dass immer

69

5 Tests

wenn sich an den Binaries des Programms etwas geändert hat, der Sicherheitsdialogerneut erscheint und manuell bestätigt werden muss. Automatische Tests werden da-durch praktisch unmöglich. Da dieses Verhalten nur in der Entwicklungsphase einesProgramms auftaucht, stellt Siemens Entwicklern mit dem Programm WhiteListEntryeinen Workaround zur Verfügung, der die Sicherheitsmeldung abschaltet. Das Pro-gramm setzt einen Registry-Eintrag, durch den die Meldung für den aktuellen Builddeaktiviert wird. Es wird als Post-Build-Event in der Debug-Konfiguration des Pro-jektes GerTi ausgeführt (siehe Listing 32).

1 if $(ConfigurationName) == Debug (2 $(ProjectDir)\..\ res\WhiteListEntry\WhiteListEntry.exe $(

TargetPath) 2>nul 1> nul3 EXIT 04 )

Listing 32: Post-Build-Event im Projekt GerTi

Besonders Fehlertests sind beim TIA-Portal wichtig, denn es können sowohl beimImport als auch beim Übersetzen der Dateien durch fehlerhafte Daten in den Excel-Tabellen Exceptions auftreten, über die der Benutzer informiert werden muss. DesWeiteren wird bei den Tests darauf geachtet, das TIA Portal ohne grafische Benutze-roberfläche zu starten, damit auch hier keine Benutzerinteraktionen nötig sind.

5.2 Manuelle Tests

Zusätzlich zu den UnitTests werden sowohl durch Entwickler als auch durch Benutzerlaufend Tests der durch die grafische Oberfläche zu erreichenden Funktionen ausge-führt. Durch diese Tests kann die Funktionsweise der Software nicht nur verfiziert,sondern auch validiert werden. (Mit der Verifikation kann festgestellt werden, ob dasSoftwareprodukt auf die richtige Art und Weise erstellt wird, also zum Beispiel, ob sichbei der Entwicklung technische Fehler eingeschlichen haben. Die Validierung beschäf-tigt sich mit der Frage, ob überhaupt die richtige Software entwickelt wird, vgl. [1,Folie 209].) Die Anforderungen an die Software können durch die Validierung im Laufeder Entwicklung weiter verfeinert und angepasst werden. Neue Anforderungen kön-nen in das Produkt-Backlog im Projektmanagement-Tool JIRA mit aufgenommenwerden.

Fehler im Programm, die durch manuelle Tests gefunden werden, können durch dieTester im JIRA als „Bug“ eingetragen, bearbeitet und später als behoben markiertwerden.

70

5.2 Manuelle Tests

Durch die manuellen Tests kann auch sichergestellt werden, dass die grafische Ober-fläche im TIA Portal korrekt angezeigt wird und dass GerTi auf das Schließen desTIA Portals durch den Benutzer richtig reagiert. Es kann zudem gezeigt werden, dassdie Software auch durch neue Benutzer leicht und intuitiv bedienbar ist.

71

6 Schlussbemerkungen

6 Schlussbemerkungen

Dieses Kapitel enthält ein Fazit des entwickelten Programms und einen Ausblick indie Zukunft. Dabei werden unter anderem einige Vor- und Nachteile der verwendetenWerkzeuge und Frameworks dargestellt und Erweiterungsmöglichkeiten von GerTiwerden dargelegt.

6.1 Fazit

Mit GerTi wurde eine Desktopanwendung zur automatischen Quellcode-Generierungentwickelt, die die Fähigkeiten des alten Programms bgen auf eine neue Plattformportiert und dessen Funktionalität erweitert. Im Rahmen des Projektes wurde mit-hilfe von WPF eine grafische Oberfläche erstellt, die dem Designmuster Model-View-ViewModel folgt. Die ursprünglichen Anforderungen an die Software konnten vollstän-dig umgesetzt werden und einem produktiven Einsatz steht nichts imWege. Wie durchdie Usertests bestätigt, kann seitens der Fachabteilung Software Design durch die Ver-wendung von GerTi viel Zeit bei der Erstellung von Anlagensoftware gespart werdenund der Einsatz des TIA Portals gegenüber dem alten STEP 7 wird maßgeblich vor-angetrieben. Durch die vereinfachte Bedienung des Tools im Gegensatz zu bgen kannmit GerTi nicht nur Anlagensoftware, sondern auch Einzelmaschinensoftware erstelltwerden. Schlussendlich unterstützt GerTi die Abteilung Softwareentwicklung damitauch bei der Einhaltung einheitlicher Code-Standards für die Maschinensoftware.

Da die Software von vielen Programmierern produktiv eingesetzt und in Zukunft nochdurch andere Entwickler erweitert werden soll, wurde besonderer Wert auf die Struk-tur und auf die Tests gelegt. Durch die Beteiligung von Experten aus verschiedenenFachgebieten ist eine gut durchdachte Software-Architektur entstanden, die sowohlerweiterbar und skalierbar ist als auch flexibel auf Änderungen an den verwendetenFrameworks reagieren kann.

Das Projekt wurde auf fünf Projects aufgeteilt, die soweit wie möglich voneinanderunabhängig sind. Im Logger-Project werden Funktionen zum Loggen von Nachrichtensowohl in der GUI als auch in Textdateien bereitgestellt, die Projects ModuleGenera-tor und PlcImporter übernehmen die Generierung der Source-Dateien beziehungsweisedie Kommunikation mit dem TIA Portal und das Project GitUpdater lädt die Vorla-gendateien für die Quellcodegenerierung aus einem zentralen Git-Repository herunter.Im Project GerTi ist schließlich die grafische Oberfläche und zentrale Modell-Logikimplementiert.

Dieser Basisarchitektur wird durch die Verwendung von verschiedenen Entwurfsmus-tern der letzte Schliff gegeben. Die grafische Oberfläche ist vollständig mit MVVM

72

6.1 Fazit

umgesetzt und setzt bei der Weiterleitung von Befehlen auf das Command-Pattern.Bei den ViewModels kommt zusätzlich zu der verwendeten Vererbungshierarchie eineKomposition für die Fenstererstellung und das Exception-Handling zum Einsatz. ImModel wird ein Singleton benutzt, um den anderen Klassen Daten zentral zur Ver-fügung zu stellen und über das komplette Projekt wird mit verschiedensten Eventsdas Observer-Pattern realisiert. Insgesamt wird so die Software nicht nur effizientund systematisch strukturiert, sondern sie wird auch durch andere Entwickler leichtnachvollziehbar.

Da die UnitTests während der Entwicklung geschrieben wurden, war eine durchgängighohe Softwarequalität gewährleistet. Durch die Tests sind die aktuellen Funktionendes Programms bei Erweiterungen gut abgesichert. Die hohe Testabdeckung ist sehrpositiv zu bewerten und stellt zusammen mit den manuellen Tests und den Integrati-onstests durch Tester und auch durch Anwender sicher, dass die Software wie erwartetfunktioniert.

Die Projektinfrastruktur mit der Verwendung von modernen Werkzeugen wie Visu-al Studio, den UnitTests, ReSharper, Git, JIRA, Confluence und Jenkins sind demgesamten Entwicklungsteam über den Projektverlauf hinweg zugutegekommen.

Die Nutzung von JIRA hat sich nicht nur für die Entwickler, sondern auch für dieTester und die Product Owner als eine Unterstützung bei der Umsetzung des Projek-tes herausgestellt. Durch die einfache Bedienung wurden selbst kleine Tasks, Issuesoder Bugs im System eingetragen, wodurch die Abarbeitung nicht vergessen wurdeund alle Team-Mitglieder besser über den Projektfortschritt informiert waren. DiePriorisierung der Tasks im JIRA und die regelmäßigen täglichen Treffen, die im Rah-men des Vorgehensmodells Scrum durchgeführt wurden, haben dafür gesorgt, dassFunktionen im Projekt richtig und zeitgemäß umgesetzt werden konnten. Das Risikofür einen Projektfehlschlag konnte somit gering gehalten werden.

Der Einsatz eines Automationsservers wie Jenkins, der die Software kompiliert undtestet, ist zwar für große Software-Projekte zweifellos sinnvoll und hat auch in diesemProjekt kleinere Fehler im Programmcode aufgedeckt, war aber auch mit einigen Ein-schränkungen verbunden. So konnten die UnitTests mit TIA- oder Git-Komponentennur auf den lokalen Rechnern und nicht auf dem Jenkins-Server ausgeführt werden.Codeänderungen, die dazu geführt hätten, dass einige dieser Komponenten nicht mehrfunktionieren, wären unter Umständen über mehrere Commits hinweg unbemerkt ge-blieben. Es musste daher stets darauf geachtet werden, die UnitTests zusätzlich aufden lokalen Rechnern auszuführen.

Da das Projekt inkrementell entwickelt wurde, konnte bei der Entwicklung schnellfestgestellt werden, welche enormen Vorteile sich aus der Verwendung von MVVMergeben. Sobald die Grundfunktionalität und benötigte Klassen im Code vorhandenwaren, skalierte die implementierte Lösung beim Hinzufügen von neuen Funktionen,also neuen Textfeldern oder Commands, sehr gut. Weder die ViewModels noch der

73

6 Schlussbemerkungen

Controller sind im Laufe der Zeit unübersichtlich geworden und es war kaum Refac-toring notwendig.

Hinsichtlich der Performance des Programms ist anzumerken, dass die Code-Generie-rung mit C# trotz des externen Zugriffs auf die Excel-Datei mit ClosedXML in GerTischneller ist, als sie es bei bgen war. Auf den Import und das Übersetzen der Datei-en im TIA kann von GerTi aus keinen Einfluss genommen werden, aber es wurdenim Programm einige Maßnahmen getroffen, um Wartezeiten im TIA Portal für denAnwender leichter nachvollziehbar zu machen.

Viele der verwendeten Programme und Framworks wurden im Rahmen dieser Arbeiterstmalig am Standort Oelde eingesetzt. So ist GerTi das erste Projekt, das eine WPF-Oberfläche konsequent nach MVVM gestaltet, Microsofts UnitTesting-Framework ein-setzt und mit Git, Jenkins und JIRA arbeitet. Die Vorgehensweise nach dem Scrum-Modell ist ebenfalls bei früheren Projekten noch nicht eingesetzt worden. Das agileModell hat sich mit seinen inkrementellen und iterativen Produktverbesserungen alssehr geeignet für das Projekt herausgestellt und zu einer präzisen Ermittlung der An-forderungen beigetragen. Entwickler, Product Owner, Tester und Anwender konntendurch GerTi wertvolle neue Erfahrungen sammeln, die in nachfolgenden Projektenherangezogen werden können.

6.2 Ausblick

Die Erweiterungsmöglichkeiten für GerTi sind sehr vielfältig. Bereits während derEntwicklung der Software sind viele neue Ideen für zukünftige Produktfeatures ent-standen, die mit in das Backlog in der Managementsoftware JIRA aufgenommen wer-den. In Zukunft können diese priorisiert und wenn gewünscht einem Sprint zugewiesenwerden, in dem die Features implementiert werden. Auf diese Art und Weise kann ei-ner kontinuierliche Weiterentwicklung und Verbesserung der Software gewährleistetwerden.

Eine dieser neuen Funktionen ist die Generierung einer sogenannten Variablentabelleim TIA Portal. In solch einer Tabelle können Hardware-Adressen im Speicher der SPSeinem Variablennamen zugewiesen werden.22 Da die Variablennamen aus dem Excel-Dokument hervorgehen, könnten sie ebenfalls zusammen mit dem SCL-Quellcodegeneriert werden. Der Import von Variablentabellen im XML-Format wird von derOpenness-Schnittstelle unterstützt.

Auch eine automatisierte Erzeugung von Teilen der grafischen Oberfläche ist im Pro-jektverlauf diskutiert worden. Da dazu verschiedene grafische Elemente auf einem Bild

22Man spricht dabei auch von symbolischer Programmierung.

74

6.2 Ausblick

durch einen Algorithmus intelligent angeordnet werden müssten, geht diese Funktionüber die einfache Generierung von Code mithilfe von Vorlagen weit hinaus.

Sinnvoll erscheint überdies ein Umstieg auf eine portable Git-Version, die in das Pro-gramm GerTi eingebettet werden kann. Damit wäre keine separate Git-Installationauf den Arbeitsplätzen notwendig und der konfigurierbare Dateipfad in der App.configwürde wegfallen.

Einige kleinere Features innerhalb des TIA Portals konnten im Projektverlauf nochnicht implementiert werden, da sie von Openness nicht unterstützt werden. Dazu ge-hören das Verschieben der fertig generierten Funktionen in einen speziellen Unterord-ner innerhalb des TIA-Projektes und das automatische Laden des neuen Programmsin eine angeschlossene Steuerung. Da Openness von Siemens noch weiterentwickeltwird, können diese Funktionen möglicherweise in einer späteren Version hinzugefügtwerden.

Mit GerTi wurden viele Komponenten, Codestücke und Strukturen entwickelt, die sichauch in zukünftigen Softwareprojekten wiederverwenden lassen. Die Projects Loggerund GitUpdater sind nicht von der Hauptfunktionalität von GerTi abhängig und kön-nen problemlos in andere Projekte eingebunden werden. Der Aufbau der grafischenOberfläche, mit den angelegten Fenstern, den ViewModels und den Commands bietetein MVVM-Grundlagenframework, das eine gute Vorlage für neue Programme dar-stellt. Dadurch können andere Softwareprojekte unter Umständen deutlich beschleu-nigt werden. Auch das gesammelte Know-How kann dafür gut eingesetzt werden.

75

Abbildungsverzeichnis

Abbildungsverzeichnis1 Separator, Quelle: [10] . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Dekanter, Quelle: [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Verwendung von Tools und Programmen bei der SW-Erstellung . . . 74 Projektinfrastruktur bei den verwendeten Entwicklungstools . . . . . 135 Eingabemaske der Anwendung FileDeleter . . . . . . . . . . . . . . . 206 Visualisierung MVVM, Quelle: Eigene Darstellung nach [5] . . . . . . 217 Vereinfachter Ablauf Maschinenentwicklung . . . . . . . . . . . . . . 228 Ausschnitt aus der Hardwareliste mit Moduldaten . . . . . . . . . . . 249 Zusammenfassung Ablauf von bgen . . . . . . . . . . . . . . . . . . . 2610 Inhalte eines bgen-Excel-Dokuments . . . . . . . . . . . . . . . . . . . 2811 Entwicklungsteam für GerTi, Quelle: GEA-interne Darstellung . . . . 3512 Architekturdiagramm GerTi . . . . . . . . . . . . . . . . . . . . . . . 3713 Vereinfachtes Klassendiagramm des Logger-Projekts . . . . . . . . . . 3914 Vereinfachtes Klassendiagramm zum Laden der Moduldaten . . . . . 4315 Vereinfachtes Klassendiagramm Bereitstellen der Modulvorlagen . . . 4416 Klassendiagramm Quellcodeerstellung . . . . . . . . . . . . . . . . . . 4517 Ablauf zur Quellcodeerstellung . . . . . . . . . . . . . . . . . . . . . . 4618 Ablauf zur Quellcodeerstellung . . . . . . . . . . . . . . . . . . . . . . 4719 Hauptfenster der Anwendung GerTi beim Start . . . . . . . . . . . . 6020 InputValidation im ConfigWindow . . . . . . . . . . . . . . . . . . . 6221 Vereinfachtes Klassendiagramm für die Anzeige der Quelldateien in der

GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6322 Ablauf beim Klick einer Datei-CheckBox in der GUI . . . . . . . . . . 6423 Ermittlung der Testergebnisse nach Project mit ReSharper . . . . . . 6524 Ermittlung der Testabdeckung mit ReSharper . . . . . . . . . . . . . 6625 Hauptfenster der Anwendung GerTi beim Start . . . . . . . . . . . . 8326 Hauptfenster der Anwendung bei einem geöffneten Projekt . . . . . . 8427 Größenveränderung des Hauptfensters . . . . . . . . . . . . . . . . . . 8528 Vergrößern der Loggingkonsole im Hauptfenster . . . . . . . . . . . . 8629 Konfigurationsfenster Tab 1 . . . . . . . . . . . . . . . . . . . . . . . 8730 Konfigurationsfenster Tab 2 . . . . . . . . . . . . . . . . . . . . . . . 8731 Konfigurationsfenster Tab 3 . . . . . . . . . . . . . . . . . . . . . . . 88

76

Tabellenverzeichnis

Tabellenverzeichnis1 Commands im MainWindowViewModel . . . . . . . . . . . . . . . . . . . 572 Commands im ConfigWindowViewModel . . . . . . . . . . . . . . . . . . 58

77

Listings

Listings1 Hello World Beispiel mit ClosedXML . . . . . . . . . . . . . . . . . . 102 Beispiel zu Properties in C# . . . . . . . . . . . . . . . . . . . . . . . 143 Beispiel zur Deklaration eines Delegates in C# . . . . . . . . . . . . . 154 Deklaration eines Events in C# . . . . . . . . . . . . . . . . . . . . . 155 Beispiel zu Tags in XAML . . . . . . . . . . . . . . . . . . . . . . . . 176 Beispieldatei MainWindow.xaml . . . . . . . . . . . . . . . . . . . . . . . 207 Beispiel für einen Modulaufruf in SCL (gekürzt) . . . . . . . . . . . . 248 Beispiel für ein Modultemplate in SCL (gekürzt) . . . . . . . . . . . . 279 Interface ILogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3810 LogLevel im Logger-Project . . . . . . . . . . . . . . . . . . . . . . . 3811 Aufruf der Methode LogMessage() . . . . . . . . . . . . . . . . . . . . 3812 App.config der Software . . . . . . . . . . . . . . . . . . . . . . . . . . 4013 Verwendung von key-value-Paaren aus der App.config . . . . . . . . . 4014 GitExecute()-Aufruf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4115 Interface IDictionaryLoader . . . . . . . . . . . . . . . . . . . . . . . 4216 Verwendung von GetTemplate() . . . . . . . . . . . . . . . . . . . . . . 4417 Methode GenerateModule() (gekürzt) . . . . . . . . . . . . . . . . . . . 4618 Singleton-Implementierung im Controller . . . . . . . . . . . . . . . . 4919 ViewModel-Basisklasse ViewModelBase . . . . . . . . . . . . . . . . . . 5220 Aufruf des PropertyChanged-Events . . . . . . . . . . . . . . . . . . . . 5221 Klasse RelayCommand (vereinfacht) . . . . . . . . . . . . . . . . . . . . 5322 Verwendung des RelayCommands im ViewModel . . . . . . . . . . . . . 5423 Wartezeiger bei längeren Operationen im ViewModel . . . . . . . . . 5524 Button mit Command-Binding im MainWindow . . . . . . . . . . . . 6025 Code-Behind des MainWindows (MainWindow.xaml.cs) . . . . . . . . . 6126 TabControl im ConfigWindow . . . . . . . . . . . . . . . . . . . . . . . 6127 Eingabevalidierung im ConfigWindow . . . . . . . . . . . . . . . . . . 6228 Angabe eines DeploymentItems in den UnitTests (gekürzt) . . . . . . . 6729 Konstruktoren der beiden ViewModels . . . . . . . . . . . . . . . . . 6830 Dummy-Klasse für IExceptionHandler . . . . . . . . . . . . . . . . . . 6831 Test des Settings-Command im MainWindowViewModel (vereinfacht) 6932 Post-Build-Event im Projekt GerTi . . . . . . . . . . . . . . . . . . . 70

78

Literatur

Literatur[1] Gernot Bauer. „Vorlesung Software Engineering“. Unveröffentlichte Folien zur

Vorlesung imWintersemester 2015/2016, FH Münster, Fachbereich Elektrotech-nik und Informatik.

[2] Microsoft Corporation. Application Configuration Files. 2016. url: https://msdn.microsoft.com/en-us/library/aa374182(v=vs.85).aspx (besuchtam 13. 06. 2016).

[3] Microsoft Corporation. CallerMemberNameAttribute Class (.NET FrameworkDocumentation). 2016. url: https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.callermembernameattribute(v=vs.110).aspx (besucht am 20. 06. 2016).

[4] Microsoft Corporation. Das Microsoft Office Open XML-Format. 2016. url:https://msdn.microsoft.com/de-de/office/bb906068.aspx (besucht am03. 06. 2016).

[5] Microsoft Corporation. The MVVM Pattern. 2016. url: https://msdn.microsoft.com/en-us/library/hh848246.aspx (besucht am 08. 07. 2016).

[6] Ecma International. Standard ECMA-376, Office Open XML File Formats.2016. url: http://www.ecma-international.org/publications/standards/Ecma-376.htm (besucht am 03. 06. 2016).

[7] Andreas Kühnel. Visual C# 2012. Kann auch als Onlinebuch unter http://openbook . rheinwerk - verlag . de / visual _ csharp _ 2012/ gelesen werden(besucht am 29.6.2016). Rheinwerk Computing, 2012.

[8] ClosedXML Project. ClosedXML – The easy way to OpenXML. 2014. url:https://closedxml.codeplex.com (besucht am 03. 06. 2016).

[9] GEA Westfalia Separator. Decanter UCF 456/466, Technical data. TechnischesDatenblatt zum Dekanter. 2016.

[10] GEA Westfalia Separator. Separator GEA Westfalia Separator hydrostop GSC200i-06-772, Technische Daten. Technisches Datenblatt zum Separator. 2015.

[11] Siemens. SIMATIC S7 Advanced Controller. 2016. url: https://mall.industry.siemens.com/mall/de/ww/catalog/products/5000008?tree=CatalogTree(besucht am 10. 06. 2016).

[12] Siemens. SIMATIC STEP 7 Professional. 2010. url: https://w3.siemens.com/mcms/simatic-controller-software/de/step7/step7-professional/Seiten/Default.aspx (besucht am 08. 06. 2016).

[13] Siemens. TIA Portal – Ihr Zugang zu mehr Engineeringeffizienz. 2016. url:http://www.industry.siemens.com/topics/global/de/tia- portal/seiten/default.aspx (besucht am 17. 06. 2016).

79

Literatur

[14] Siemens. TIA Portal Openness: Einführung und Demoanwendung. 2015. url:https://cache.industry.siemens.com/dl/files/692/108716692/att_830999 / v1 / 108716692 _ TIA _ Openness _ GettingStartedAndDemo _ de . pdf(besucht am 17. 06. 2016).

[15] International Organization for Standardization. ISO/IEC 29500-1:2012. 2012.url: http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=61750 (besucht am 03. 06. 2016).

[16] Microsoft Open Technologies. OfficeDev/Open-XML-SDK. 2016. url: https://github.com/OfficeDev/Open-XML-SDK (besucht am 03. 06. 2016).

80

Glossar

Glossar

ASCII American Standard Code for Information Interchange, Kodierung mit der denZahlen 0-127 ein Zeichen (zum Beispiel ein Buchstabe, eine Zahl oder ein Steu-erzeichen) zugewiesen wird..

DLL Dynamic Link Library, Dateiformat für Programmbibliotheken, vornehmlichvon Microsoft verwendet.

GUI Abkürzung für graphical user interface (dt.: grafische Benutzeroberfläche).

HMI Human Machine Interface (dt: Mensch-Maschinen-Schnittstelle). Ein Compu-ter, der sich mit einer Speicherprogrammierbaren Steuerung verbindet und ei-nem Benutzer eine grafische Oberfläche zur Bedienung der Maschine liefert.

HW Hardware.

IDE Integrated Development Environment (dt. integrierte Entwicklungsumgebung),eine Zusammenstellung verschiedener Programme zur Erstellung und Verwal-tung von Software.

MVVM Model-View-ViewModel, ein Designmuster ähnlich Model-View-Controllerzur Trennung von GUI und Logik in Anwendungsprogrammen mit grafischenOberflächen.

PID Piping and Instrumentation Diagram bzw. Piping and Installation Diagram, oftP&ID abgekürzt, ist ein Diagramm in dem der Produktfluss und installierteGeräte (zum Beispiel Ventile, Motoren, etc.) visualisiert sind.

PLC Programmable Logic Controller, siehe SPS.

SDK Software Development Kit. In einem SDK sind verschiedene Klassen oder auchganze Programme zusammengefasst, die Entwicklern Funktionalitäten für einbestimmtes Programm oder ein Gerät bereitstellen, oft um mit dem Programmoder Gerät zu kommunizieren.

81

Glossar

SPS Speicherprogrammierbare Steuerung (engl: Programmable Logic Controller, PLC).Ein programmierbares Gerät zur Steuerung einer großen Maschine oder einerAnlage.

STEP7 Programm von Siemens zur Programmierung von SpeicherprogrammierbarenSteuerungen. Wird bei GEA sowohl in der Version 5.5 als auch in einer imTIA Portal integrierten Version verwendet. In diesem Dokument ist mit derBezeichnung STEP 7 stets die Version 5.5 und nicht eine der in das TIA Portalintegrierten Versionen gemeint.

SW Software.

TIA Portal Totally Integrated Automation Portal, Tool von Siemens zur Program-mierung von Speicherprogrammierbaren Steuerungen und deren grafischen Be-dienoberflächen.

VBA Visual Basic for Applications, Skriptsprache zur Automatisierung von Prozes-sen in Microsoft-Office-Dokumenten.

WPF Windows Presentation Foundation. Framwork von Microsoft zur Erstellungvon grafischen Benutzeroberflächen (GUIs). Als Nachfolger von Windows Formsangesetzt.

WYSIWYG Abkürzung für What you see is what you get. Wird häufig als Bezeich-nung für grafische Editoren verwendet, bei denen nicht der zugrunde liegendeProgrammcode einer Seite angezeigt wird, sondern das endgültige Aussehen.Ein Beispiel für einen WYSIWYG-Editor ist Microsoft Word (im Gegensatz zurErstellung von Dokumenten mit dem Typesetting-Tool LATEX).

XAML eXtensible Application Markup Language, eine von Microsoft entwickelte,XML-basierte Beschreibungssprache zum Erstellen und Definieren von grafi-schen Oberflächen.

82

A Screenshots der Anwendung

A Screenshots der Anwendung

A.1 Hauptfenster beim Programmstart

Abb. 25: Hauptfenster der Anwendung GerTi beim Start

83

Glossar

A.2 Hauptfenster bei geöffnetem Projekt

Abb. 26: Hauptfenster der Anwendung bei einem geöffneten Projekt

84

A Screenshots der Anwendung

A.3 Größenveränderung des Hauptfensters

Abb. 27: Größenveränderung des Hauptfensters

85

Glossar

A.4 Vergrößern der Loggingkonsole im Hauptfenster

Abb. 28: Vergrößern der Loggingkonsole im Hauptfenster

86

A Screenshots der Anwendung

A.5 Konfigurationsfenster Tab 1

Abb. 29: Konfigurationsfenster Tab 1

A.6 Konfigurationsfenster Tab 2

Abb. 30: Konfigurationsfenster Tab 2

87

Glossar

A.7 Konfigurationsfenster Tab 3

Abb. 31: Konfigurationsfenster Tab 3

88

Erklärung

Ich versichere, die von mir vorgelegte Arbeit selbstständig verfasst zu haben. AlleStellen, die wörtlich oder sinngemäß aus veröffentlichten oder nicht veröffentlichtenArbeiten anderer entnommen sind, habe ich als entnommen kenntlich gemacht. Sämt-liche Quellen und Hilfmittel, die ich für die Arbeit benutzt habe, sind angegeben.

Steinfurt, der 8. Juli 2016