Upload
hoangtuyen
View
216
Download
0
Embed Size (px)
Citation preview
Steuerungsvisualisierung mit .NET/WPF
Bericht zur Master Thesis
MT-11.01.08 | 20.09.2011
Student
Röthlisberger Simon
Ammann Schweiz AG, Güterstrasse 20 | 4901 Langenthal
+41 (62) 916 6551
Betreuer Hauri Andreas
Ammann Schweiz AG, Güterstrasse 20 | 4901 Langenthal
+41 (62) 916 6411
Experte Wenger Rolf
weroSoft GmbH, Steingrübliweg 8a | 3072 Ostermundigen
Abstract In der Automations-Industrie wird die grafische Darstellung immer wichtiger. In diesem Vorprojekt soll
anhand eines Prototyps die Möglichkeit untersucht werden, die Ammann Anlagen Steuerungen mit .NET
und Windows Presentation Foundation zu realisieren.
Schlüsselwörter Steuerung, Visualisierung, .NET, WPF, C#
Klasse MAS-IT-11-01
Seite II
Management Summary
Ausgangslage Die Firma Ammann Schweiz AG produziert Anlagen für die Herstellung von Asphalt und
Beton sowie den Bau von Kieswerken. Die dafür notwendige Steuerung sowie das
Dispositionssystem werden ebenfalls durch die firmeneigene Softwareabteilung entwickelt.
In diesem Vorprojekt wurde anhand eines Prototyps aufgezeigt, ob es möglich ist, die
Ammann Steuerungsvisualisierung mit der neuen .NET/WPF- Technologie zu realisieren.
WPF oder Windows Presentation Foundation ist die aktuelle Technologie von Microsoft für
das Erstellen von Benutzeroberflächen. Die Hauptaspekte, welche bei dieser Arbeit beleuchtet wurden:
• Wie werden Automations-Elemente erstellt?
• Wie werden Automations-Elemente dargestellt?
• Wie wird mittels Pcs-Nachrichten mit dem RTC (Real Time Controller) kommuniziert?
Fazit und Ausblick Mit dem Prototyp wurde aufgezeigt, dass es technisch möglich ist, mit .NET und WPF die
Steuerungsvisualisierung der Firma Ammann Schweiz AG zu realisieren.
Wie werden die Automations-Elemente erstellt?
Mit einer Präferenz Matrix und einer Nutzwert-Analyse wurden verschiedene Varianten
durchgespielt, wie die Automations-Elemente erstellt werden können. Dabei kristallisierte
sich heraus, dass für die Firma Ammann Schweiz AG die reine C# Lösung mit MVVM (Model
View ViewModel) sich als bester Ansatz darstellt.
Wie werden Automations-Elemente dargestellt?
Die einzelnen Automations-Elemente werden als UserControls entwickelt, welche dann über
einen geeigneten Mechanismus geladen und in einem Canvas-Element dargestellt werden.
Wie wird über Pcs-Nachrichten mit dem RTC (Real Time Controller) kommuniziert?
Die Pcs-Nachrichten können, wie im Prototypen realisiert, direkt über C# gesendet und
empfangen werden. Dazu werden zu den C++ Strukturen des Real Time Controllers in C#
Klassen für das Marshalling definiert und benutzt.
Wie bereits erwähnt, ist es technisch realisierbar; es gibt jedoch noch andere Aspekte,
welche für eine komplette Realisierung dieses Projektes berücksichtigt werden müssen.
• Lohnt sich der Aufwand?
• Wie werden die Engineerings geschult?
• Umsetzung schrittweise oder Big Bang?
Anhand des entwickelten Prototyps lässt sich genauer untersuchen, welche Vor- und
Nachteile diese neue Technologie mit sich bringen wird, und wie das komplette Projekt am
besten realisiert werden kann.
Seite III
Inhaltsverzeichnis Management Summary ........................................................................................................................... II
Inhaltsverzeichnis ................................................................................................................................... III
Einleitung ......................................................................................................................................... 1 1
1.1 Änderungskontrolle ................................................................................................................. 1
1.2 Referenzierte Dokumente ....................................................................................................... 1
1.3 Glossar ..................................................................................................................................... 1
1.4 Vorgehensweise ...................................................................................................................... 2
1.5 Projektplanung ........................................................................................................................ 3
Analyse ............................................................................................................................................ 4 2
2.1 Einleitung ................................................................................................................................. 4
2.2 Auflistung der Anforderungen................................................................................................. 4
2.3 Zerlegung des Systems ............................................................................................................ 5
2.4 Entscheidung, wie Automations-Element erstellen ................................................................ 6
Grundlagen .................................................................................................................................... 15 3
3.1 Einleitung ............................................................................................................................... 15
3.2 Abhängigkeiten und Erweiterbarkeit von Software-Komponenten ...................................... 15
Design ............................................................................................................................................ 19 4
4.1 Einleitung ............................................................................................................................... 19
4.2 Einleitung Architektur............................................................................................................ 19
4.3 System-Architektur ................................................................................................................ 20
4.4 Automations-Element erstellen ............................................................................................ 22
4.5 Automations-Elemente dynamisch laden ............................................................................. 25
4.6 Automations-Elemente darstellen ........................................................................................ 27
4.7 Dynamik der Benutzeroberfläche.......................................................................................... 30
4.8 Design-Modus ........................................................................................................................ 31
4.9 Kundenspezifische Automations-Elemente erstellen ........................................................... 36
4.10 Pcs-Nachrichten ..................................................................................................................... 37
Implementation ............................................................................................................................. 43 5
5.1 Einleitung ............................................................................................................................... 43
5.2 Allgemein .............................................................................................................................. 43
5.3 Initialisieren der Anwendung ................................................................................................ 44
5.4 Gui Design Prototyp .............................................................................................................. 44
Testen der Anforderungen ............................................................................................................ 45 6
6.1 Anforderungen ...................................................................................................................... 45
Seite IV
6.2 Code Analyse ......................................................................................................................... 45
6.3 Abnahmekriterien ................................................................................................................. 46
6.4 Unit Tests ............................................................................................................................... 47
6.5 Performance .......................................................................................................................... 48
Fazit ............................................................................................................................................... 50 7
7.1 Was wurde erreicht? ............................................................................................................. 50
7.2 Wie geht es weiter? ............................................................................................................... 50
7.3 Erfahrungen ........................................................................................................................... 50
7.4 Schlusswort ........................................................................................................................... 51
Anhang........................................................................................................................................... 52 8
8.1 Literaturverzeichnis ............................................................................................................... 52
8.2 Abbildungsverzeichnis ........................................................................................................... 53
8.3 Iterations-Plan ....................................................................................................................... 54
Einleitung Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 1 von 59
Einleitung 1
In diesem Dokument wird die Master Thesis zum Thema Steuerungsvisualisierung mit .NET/WPF
beschrieben. In diesem Vorprojekt soll anhand eines Prototyps aufgezeigt werden, ob es möglich ist,
die Ammann Steuerungsvisualisierung mit .NET/WPF zu realisieren.
Die Anforderungen werden im Dokument [Dok1] beschrieben.
Dieses Dokument ist dem Entwicklungsprozess entsprechend strukturiert.
Die im Dokument [Dok1] beschriebenen Anforderungen werden zuerst analysiert. Danach werden
die entsprechenden theoretischen Grundlagen erarbeitet. Daraus wird ein Konzept erstellt, damit die
Anforderungen erfüllt werden können. Anschliessend entsteht ein kleiner Prototyp, an welchem die
Grundprinzipien des Konzeptes überprüft werden können.
Dieses erste Kapitel soll eine kurze Einführung in das Thema geben und die Arbeitsweise erklären.
1.1 Änderungskontrolle
Änderungskontrolle, Prüfung, Genehmigung
Wann Version Wer Beschreibung
20.04.2011 0.1 S. Röthlisberger Erstellung der Anforderungen
25.05.2011 0.2 S. Röthlisberger Analyse: Varianten und Bewertung erstellt
20.06.2011 0.3 S. Röthlisberger Design
25.07.2011 0.4 S. Röthlisberger Implementation Anzeige
29.08.2011 0.5 S. Röthlisberger Implementation Nachrichtenvermittlung
15.09.2011 0.6 S. Röthlisberger Korrektur
20.09.2011 1 S. Röthlisberger Fertigstellung
1.2 Referenzierte Dokumente
Die hier aufgeführten Dokumente sind der Zip-Datei mit den Anhängen beigelegt.
Referenz Name des Dokumentes
[Dok1] Pflichtenheft-Steuerungsvisualisierung mit .NetWPFV1.1.pdf
1.3 Glossar
Name Bezeichnung
Anlage Asphalt- oder Beton-Anlage, welche die Firma Ammann Schweiz AG
herstellt.
As1 Konsole As1 ist die Anwendung, in der alle Fachmodule laufen. Der Benutzer kann
über die Navigation zwischen unterschiedlichen Ansichten und
Fachmodulen umschalten.
Automations-Element Ein Element, welches abgebildet wird; z.B. Band, Silo oder Waage.
Baukasten In der Steuerung werden die Automations-Elemente entwickelt und im
Baukasten bereitgestellt. Mit den Automations-Elementen im Baukasten
Einleitung Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 2 von 59
können die Anlagen konfiguriert werden.
C++ / CLI Eine C++ Spracherweiterung für .NET.
Code Behind Zu einem User Control gehörender Code, welcher zum Beispiel für das
Implementieren von Event Handlern verwendet werden kann.
COM Objekt Das Component Object Model wurde von Microsoft für das
Betriebssystem Windows entwickelt. Es ermöglicht eine Interprozesskommunikation.
Fachmodule Dies sind verschiedene Software-Komponenten, welche in die As1 Konsole geladen werden.
IOs Hardware Ein- und Ausgänge, welche über ein Bussystem gesteuert
werden.
MOM Message Oriented Middleware oder Nachrichtenorientierte Middleware
bezeichnet Middleware, welche Nachrichten asynchron oder synchron
vermittelt.
PcsMsgDispatcher Vermittelt die Nachrichten asynchron zwischen den verschiedenen
Systemen. Dies ist eine von Ammann Schweiz AG entwickelte MOM
Lösung.
Pcs-Nachricht Eine von Ammann definierte, Message orientierte Nachricht, welche für
die Kommunikation zwischen Real Time Controller und Visualisierung
benutzt wird.
PCV: Process
Visualization
Fachmodule der aktuellen As1, welche die Steuerungsvisualisierung
anzeigt.
RTC: Real Time
Controller
In dieser von Ammann Schweiz AG entwickelten Anwendung, welche
unter Echtzeit läuft, wird die Logik der Steuerung verarbeitet. Die
Echtzeiterweiterung für Windows ist ein Produkt von IntervalZero.
Design-Modus Modus der Steuerungsvisualisierung, in dem die Automations-Elemente
grafisch für den Kunden eingerichtet werden können.
Typenbezeichnung Typenbezeichnung eines Automations-Elementes. Wie z.B. AuvWaage
oder AuvSilo.
Avo Control Unterelement eines Automations-Elementes.
1.4 Vorgehensweise
Als Vorgehensweise wird der Agile Unified Process benutzt. Dies ist ein für agile Arbeitsweise angepasster
Unified Process. Die Phasen dieses Unified Processes bleiben aber dieselben des originalen. Nur die Disziplinen
wurden angepasst. Die detaillierte Iterations-Planung ist dem Anhang beigelegt.
Im Kapitel 1.5 wird die Projektplanung für dieses Projekt genauer beschrieben.
Abbildung 1 Agile Unified Process (Quelle http://www.ambysoft.com)
Einleitung Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 3 von 59
1.5 Projektplanung
Die Arbeit wird iterativ nach den Phasen des Unified Prozesses durchgeführt. Dabei sieht die Wochenplanung so aus, dass pro Arbeitswoche primär je Freitag
und Samstag an der Master Thesis gearbeitet wird. Wie unten im Gantt-Diagramm zu sehen ist, ist in den ersten beiden Augustwochen ein Urlaub eingeplant. Dabei wird die Arbeit kurz unterbrochen.
� Inception / Konzeptionsphase: In dieser ersten Phase des Projektes geht es darum, sich in das Projekt einzuarbeiten, das vorhandene System zu
analysieren und Anforderungen zu sammeln und zu erfassen.
� Elaboration / Entwurfsphase: In dieser Phase werden Lösungen zu den konkreten Problemen gesucht und es wird ein Design für die Applikation
erstellt.
� Construction / Konstruktionsphase. In dieser Phase wird der Prototyp erstellt.
� Transition / Übergabephase: In dieser letzten Phase werden Abschluss-Tests durchgeführt und die Dokumentation wird abgeschlossen.
� Pflichtenheft fertig gestellt: Bei diesem Meilenstein soll das Pflichtenheft fertiggestellt sein. Dabei sollen auch die Bewertungskriterien für die
Entscheidung, wie die Automationselemente programmiert werden, enthalten sein.
� Entscheid, wie Automationselemente programmieren: Bei diesem Meilenstein soll entschieden werden, in welcher Form die Automationselemente programmiert werden. Dabei soll festgelegt werden, wo die Schnittstelle zwischen C++ und .Net liegt. Da dieser Entscheid die gesamte Architektur
beeinflusst, muss er früh getroffen werden.
� Grundkonzept / Design stabil: Bei diesem Meilenstein soll das Grunddesign so stabil sein, dass mit der Programmierung begonnen werden kann.
� Prototyp fertig: Bei diesem Meilenstein soll der Prototyp fertiggestellt sein.
� Definitiver Projektantrag und Abstract (Diplomplattform): Bei diesem Meilenstein sollen die beiden Dokumente fertig erstellt und hochgeladen sein.
� Upload der fertigen Master Thesis (Diplomplattform): Bei diesem Meilenstein soll die Arbeit abgeschlossen und hochgeladen sein.
Nr. Vorgangsname Anfang Fertig stel len
1 Inception (Analyse / Anforderungen) Fr 01.04.11 Do 05.05.112 Pflichtenheft fertiggestellt Do 05.05.11 Do 05.05.11
3 Elaboration (Konzept / Design) Fr 06.05.11 Do 23.06.11
4 Entscheid, wie Automations-Elemente programmieren Do 26.05.11 Do 26.05.115 Grundkonzept / Design stabil Do 23.06.11 Do 23.06.11
6 Construction (Erstellen) Fr 24.06.11 Sa 03.09.11
7 Prototyp fertig So 04.09.11 So 04.09.11
8 Transition (Testen / Dokumentation abschliessen) So 04.09.11 Fr 16.09.119
10 Definitiver Projektantrag und Abstract (Diplomplattform)Mo 23.05.11 Mo 23.05.11
11 Upload der fertigen Master Thesis (Diplomplattform)Do 22.09.11 Do 22.09.11
05.05.
26.05.
23.06.
04.09.
23.05.
22.09.
28. 04. 11. 18. 25. 02. 09. 16. 23. 30. 06. 13. 20. 27. 04. 11. 18. 25. 01. 08. 15. 22. 29. 05. 12. 19. 26. 03.Apr '11 Mai '11 Jun '11 Jul '11 Aug '11 Sep '11 Okt '11
Analyse Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 4 von 59
Analyse 2
2.1 Einleitung
In der Analyse geht es darum, die Anforderungen zu analysieren, um später daraus ein Design zu
erarbeiten.
Das wichtigste Grundprinzip hierbei ist: Teile und herrsche.
2.2 Auflistung der Anforderungen
In der unten stehenden Tabelle sind die Anforderungen aus dem Dokument [Dok1] zusammengefasst
aufgelistet.
Kennung Prio. Bezeichnung der Anforderung
AF-1 muss Pcs-Nachrichten empfangen
AF-2 muss Nach empfangen, Pcs-Nachricht bereitstellen
AF-3 muss Pcs-Nachrichten senden
AF-4 muss Vor dem senden, Pcs-Nachricht Format anpassen
AF-5 muss Automations-Element erstellen
AF-6 muss Darstellungslogik programmieren
AF-7 muss Interaktion mit Benutzeroberfläche
AF-8 soll Verschiedene Darstellungsvarianten eines Automations-Elementes erstellen
AF-9 soll Darstellungsvarianten umschalten
AF-10 soll Kundenspezifisches Automations-Element neu erstellen
AF-11 soll Automation-Element kundenspezifisch anpassen
AF-15 muss Automations-Elemente anzeigen
AF-16 soll Layer einstellen
AF-17 kann Im Design-Modus: Automations-Element einfügen
AF-18 kann Design Modus ein-/ausschalten
AF-19 kann Im Design-Modus: Automations-Elemente benennen
AF-20 kann Im Design-Modus: Automations-Elemente verschieben
AF-21 kann Avo Control erstellen
AF-22 kann Avo Control: Pcs-Nachrichten senden und empfangen
AF-24 kann Fehlerzustand eines Automations-Elementes
AF-25 kann Dynamik der Benutzeroberfläche
AF-26 muss Unabhängiger .NET Prototyp
AF-27 kann Neue .NET Visualisierung in vorhandener Applikation
AF-28 As1 mit .NET
Analyse Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 5 von 59
2.3 Zerlegung des Systems
Bei genauerer Betrachtung der Anforderungen lassen sich folgende Schwerpunkte erkennen:
• Wie werden Automations-Elemente erstellt?
• Wie werden Automations-Elemente dargestellt?
• Wie wird mittels Pcs-Nachrichten mit dem RTC (Real Time Controller) kommuniziert?
• Was bietet WPF für Möglichkeiten?
In Abbildung 2 sind die vier Schwerpunkte grafisch dargestellt. Automations-Elemente werden
erstellt und dargestellt. Pcs-Nachrichten können gesendet und empfangen werden. Und Punkt vier steht für „Was bietet WPF für Möglichkeiten?“.
Abbildung 2 Zerlegung des Systems
In der unten stehenden Auflistung werden die Kategorien mit den Kapiteln aus dem Dokument
verknüpft.
1. Automations-Elemente erstellen
a. Entscheidung, wie Automations-Elemente erstellt werden (Kapitel 2.4)
b. Konzept Automations-Elemente erstellen (Kapitel 4.4)
c. Kundenspezifische Automations-Elemente erstellen (Kapitel 4.9)
2. Automations-Elemente darstellen
a. Abhängigkeit und Erweiterbarkeit von Software Komponenten (Kapitel 3.2)
b. System-Architektur. (Kapitel 4.3)
c. Automations-Elemente dynamisch laden (Kapitel 4.54.4.3)
d. Automations-Elemente darstellen (Kapitel 4.6)
3. Pcs-Nachrichten senden / empfangen
Analyse Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 6 von 59
a. Pcs-Nachrichten (Kapitel 4.10)
4. Möglichkeiten von WPF?
a. Design-Modus (Kapitel 4.8)
b. Dynamik der Benutzeroberfläche (Kapitel 4.7)
c. GUI Design Prototyp (Kapitel 5.4)
2.4 Entscheidung, wie Automations-Element erstellen
Ein sehr entscheidender Punkt für das System ist das Erstellen von Automations-Elementen. Über
längere Zeit gesehen wird die meiste Entwicklungszeit in das Erstellen von Automations-Elementen
investiert. Somit ist es sehr entscheidend, hier die geeignete Variante zu finden.
2.4.1 WPF Control
In WPF wird zur Erstellung der grafischen Oberfläche XAML (Extensible Application Markup
Language) eingesetzt. XAML-Code kann in der Entwicklungs-Umgebung des Microsoft Visual Studios
oder in Expression Blend bearbeitet werden. Um die Automations-Elemente zu entwickeln, gibt es
verschiedene Basis Controls, welche verwendet werden können. Dies ist mit folgenden Controls
möglich: (MacDonald, 2008)
Window
Entspricht einem Fenster, wie es aus Windows XP oder Windows 7 bekannt ist. Da es nur als einzelnes Fenster angezeigt werden kann, ist es für das Erstellen von Automations-Elementen
ungeeignet.
Custom Control
Custom Controls sind zum Beispiel Buttons oder Listboxen. Dabei wird in den Controls nur die Logik
programmiert, das Aussehen wird über Themes oder Styles vorgegeben. Diese können aber nur
begrenzt grafisch designet werden. Daher sind sie nicht geeignet. Sie können in ein Fenster oder in
ein User Control geladen werden.
User Control
Ein User Control besteht aus zwei Dateien: erstens aus der XAML Datei, wo die Darstellung als xml
abgelegt ist, und zweitens aus einer Code Behind Datei, in welcher die Logik oder Eventhandler
implementiert werden können. Diese können in ein anderes User Control oder in ein Fenster geladen
werden.
Fazit
Für unseren Anwendungsfall ist das User Control am besten geeignet.
Analyse Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 7 von 59
2.4.2 C++/CLI allgemein
Um zu untersuchen, ob Automations-Elemente mit C++ programmiert werden könnten, wird in
diesem Abschnitt eine kurze Übersicht über C++/CLI erarbeitet.
C++/CLI ist eine C++ Spracherweiterung, um mit C++ .NET CLI Code (gemanagten Code) zu erzeugen.
(Fraser, 2008)
2.4.2.1 Unterschied Ansi C++, C# und C++/CLI
In der unten stehenden Tabelle wird anhand einiger Sprachkonstrukte aufgezeigt, wie sich die
Sprachen unterscheiden. Dabei ist zu beachten, dass sich C++/CLI gegenüber dem Ansi C++ durch den
gemanagten Code wesentlich unterscheidet.
Tabelle 1 Unterschied Sprachen
Ansi C++ C# C++/CLI
Klasse Class Punkt {} Class Punkt {} ref class Punkt {}
Struct struct xy {} -> wie
klasse
struct xy{} -> ValueTyp ref struct xy {} -> Value Typ
Enum enum ETest
{
eA = 0,
eB };
enum ETest
{
eA = 0,
eB }
Enum class ETest
{
eA = 0,
eB };
Neues Objekt T* pTest = new T(); T Test = new T(); T^ Test = gcnew T();
Listen Array Collection Collection array<MyClass ^> ^
My1DArray = gcnew
array<MyClass ^>(100);
for for(;;){} for(;;){} for(;;){}
while while(true){} while(true){} while(true){}
Foreach - foreach () for each(FileInfo ^ finfo in
dinfo->GetFiles(pattern));
{
Console::WriteLine(finfo-
>FullName);
}
LINQ - Expression<Func<bar,
int>> lam = x => x.baz + 3
Expression^ foo =
Expression::Add(
Expression::Field( Expression::Constant(feh),
barDotBaz),
Expression::Constant(3));
VS2010
IntelliSense
Nein Ja Nein
Analyse Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 8 von 59
2.4.2.2 Einschränkungen: WPF und C++
Für das Programmieren von WPF im Zusammenhang mit C++ gibt es einige Einschränkungen.
• WPF kann als Code Behind nur mit C#, Visual Basic oder F# umgehen. Diese Einschränkung
wird von Microsoft vorgegeben. Somit ist es nicht möglich, WPF direkt mit C++ zu
programmieren.
• Weiter gibt es die Einschränkung, dass in einer Assembly nicht C# und C++ gemischt werden
kann. Diese müssen vom Compiler je in eine unterschiedliche Assembly kompiliert werden.
Diese Einschränkungen haben einen grossen Impact auf die Varianten mit C++.
Deshalb wird für die konzeptionellen Varianten der Schwerpunkt auf die Einschränkungen der
verschiedenen Varianten gelegt. Somit können Design-Fehler für die konzeptionellen Varianten
minimiert werden.
2.4.3 Varianten
In diesem Abschnitt werden die vier Varianten beschrieben. Für die Bezeichnung der Libraries
werden zur besseren Verständlichkeit die Namen des abzulösenden Systems verwendet. Dies
bedeutet nicht, dass in der endgültigen Architektur auch diese Namen verwendet werden. PCV: Element, welches die Automations-Elemente anzeigt
AutViewLib: Baukasten, worin die einzelnen Elemente gespeichert werden
VisuFrw: Grundfunktionalitäten wie Basisklassen
2.4.3.1 C++/CLI
Bei dieser Variante werden die Automations-Elemente mit C++/CLI erstellt. WPF muss in einer
eigenen C# Assembly implementiert werden.
cmp C++/CLI
Autv iewLib C# AutViewLib C++/CLI
VisuFrw C++/CLIVisuFrw C#
«User Control»Autv iewLib C#::Mischer
AutViewLib C++/CLI::MischerPCV
«use»
«use»
«use»«use»
«use»
«use»«use»
Analyse Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 9 von 59
Vor- und Nachteile dieser Varianten:
• C++/CLI ist eigentlich eine neue Sprache.
Sie arbeitet nicht mehr nach den Konzepten von C++. Eine C++ Syntax für C# wäre wohl
treffender. Vergleich der Sprachen siehe 2.4.2.1.
Dies würde bedeuten, dass in der Firma eine neue Sprache eingeführt wird.
• User Control und die Anzeigelogik sind nicht in derselben Assembly.
• Der C# Code Behind des User Control kann, bei konsequenter Nutzung von C++/CLI, nicht
benutzt werden. Siehe dazu 2.4.2.2.
2.4.3.2 Unsafe C++
Bei dieser Variante wird die Möglichkeit ausgenutzt, dass in C++/CLI auch Unsafe C++ Code (Code wie
ANSI C++) programmiert werden kann. Dieser Unsafe C++ Code kann über einen gemanagten C++/CLI
Wrapper in C# aufgerufen werden.
Abbildung 3 Unsafe C++ Variante
Code-Beispiel für einen Generic C++ Wrapper Im folgenden Beispiel wird aufgezeigt, wie ein Generic Wrapper für C++/CLI zu Unsafe C++
funktionieren könnte. Dabei wird eine Methode über den Wrapper auf der Unsafe C++ Klasse
aufgerufen.
Nach diesem Prinzip könnte die gesamte Kommunikation zwischen Anzeige und Anzeigelogik implementiert werden. // Hier wird der Generic Wrapper getestet. GenericWrapper<UnsafeTestClass>^ genericWrapper = gcnew GenericWrapper<UnsafeTestClass>();
genericWrapper->Test();
cmp Unsafe C++
Autv iewLib C# AutViewLib C++/CLI
VisuFrw C++/CLI
VisuFrw C#
«User Control»Autv iewLib C#::Mischer
AutViewLib C++/CLI::Mischer Nativ ePCV.NET
VisuFrw C++/CLI::Generic Wrapper
«use»
«use»
«use»«use»
«use» «use»
«use»
Analyse Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 10 von 59
////////////////////////////////////////////////////////////////////////// // Diese Klasse dient als Wrapper zwichen C++/CLI und Unsafe C++.
////////////////////////////////////////////////////////////////////////// template <typename T> public ref class GenericWrapper { public: void Test() { T* pT = new T; pT->Test(); } };
////////////////////////////////////////////////////////////////////////// // Diese Klasse wird Unsafe implementiert. // Dies würde der Anzeigelogik entsprechen. ////////////////////////////////////////////////////////////////////////// public class UnsafeTestClass { public: void Test() { ; }
};
Vor- und Nachteile dieser Varianten:
• Durch den C++/CLI Wrapper ist die Kommunikation zwischen User Control und Anzeigelogik
vorgegeben (begrenzt). Möglichkeiten von WPF und DataBinding können nicht voll
ausgeschöpft werden.
• User Control und die Anzeigelogik sind nicht in derselben Assembly.
• Der C# Code Behind des User Control kann, bei konsequenter Anwendung von C++, nicht
benutzt werden. Siehe dazu 2.4.2.2.
2.4.3.3 C# Code Behind
Bei dieser Variante wird das Automations-Element in C# programmiert. Die Anzeigelogik wird direkt
im Code Behind programmiert.
Abbildung 4 C# Code Behind Variante
cmp C# Code Behind
PCV.NET
AutViewLib C#
VisuFrw C#«User Control»AutViewLib C#::Mischer
«use»
«use»
Analyse Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 11 von 59
• Für Engineering neue Sprache.
• Keine Trennung von Anzeigegrafik und Anzeigelogik. Dies ist zum Beispiel fürs Testen wichtig.
• Möglichkeiten von WPF können voll genutzt werden.
2.4.3.4 C# MVVM
Bei dieser Variante wird das Automations-Element mit C# und MVVM programmiert.
Was heisst MVVM?
Bei WPF gibt es die Möglichkeit, Daten zu binden. Das heisst, die Darstellung holt sich die Daten, welche sie benötigt. Werden die Daten verändert, wird die Darstellung mittels Event darüber
informiert und diese holt sich dann die Daten erneut.
Abbildung 5 WPF DataBinding (Hall, 2010)
Mit diesem DataBinding ist es nun möglich, die Anzeigegrafik und die Anzeigelogik zu trennen. Dazu
wird das Pattern MVVM (Model View ViewModel) oder nach Martin Fowler Presentation Model
verwendet.
View: XAML Code, welcher der grafischen Darstellung entspricht. Der Code Behind wird nur
ausnahmsweise benutzt.
ViewModel: Stellt die Daten für die View gerecht zur Verfügung.
Model: Enthält die Daten, welche zum Beispiel aus einer Datenbank gelesen werden.
Im Fall der Automations-Elemente entspricht das Model in den meisten Fällen den Pcs-Nachrichten.
Abbildung 6 MVVM
class MVVM
View
ViewModel
Model
XAML
C#
Analyse Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 12 von 59
In dem Diagramm unten wird ein möglicher Aufbau aufgezeigt. Dabei wurde auf das Model
verzichtet, weil dieses meistens den Pcs-Nachrichten entspricht.
Abbildung 7 C# MVVM Variante
Vor- und Nachteile dieser Varianten:
• Für Engineering neue Sprache
• Trennung von Anzeigegrafik und Anzeigelogik
• Möglichkeiten von WPF können voll genutzt werden
• Anzeigelogik kann für kundenspezifisches Element vererbt werden
2.4.4 Entscheidung
Die Entscheidung, welche Variante für die Firma Ammann Schweiz AG am besten geeignet ist, wird
anhand einer Präferenz-Matrix und Nutzwert-Analyse getroffen. Diese Beurteilung wird im Team und
nach bestem Wissen und Gewissen durchgeführt. Sie stellt keine rein wissenschaftliche Beurteilung dar.
Die Kategorien der Entscheidungskriterien wurden in verschiedene Kategorien eingeteilt. Die
Legende dazu sieht folgendermassen aus:
cmp C# MVVM
PCV.NET
AutViewLib C#
VisuFrw C#«User Control»
AutViewLib C#::MischerAutViewLib C#::Mischer
View Model«use»
«use»
Analyse Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 13 von 59
Abbildung 8 Präferenz-Matrix
Analyse Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 14 von 59
Wie oben zu sehen ist, fällt die Entscheidung sehr eindeutig in Richtung reine C#-Lösung aus. Die MVVM-Variante wird dabei bevorzugt. Nachdem nun diese
wichtige Entscheidung getroffen ist, werden die Konzepte darauf aufgebaut.
Abbildung 9 Nutzwert-Analyse
Grundlagen Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 15 von 59
Grundlagen 3
3.1 Einleitung
Nachdem nun die Anforderungen analysiert wurden und die Grundsatzentscheide getroffen sind,
werden hier in diesem Kapitel Grundlagen für dieses Projekt erarbeitet.
Wenn Sie, lieber Leser, sich bereits mit Abhängigkeiten und Erweiterbarkeit von Software auskennen,
können Sie dieses Kapitel einfach überspringen.
3.2 Abhängigkeiten und Erweiterbarkeit von Software-Komponenten
In diesem Kapitel werden einige Grundlagen erarbeitet, wie eine moderne .NET Applikation
aufgebaut werden kann.
Diese Grundlagen sind für dieses Projekt in zweierlei Hinsicht wichtig:
• Wie können die Automations-Elemente geladen werden?
• Wie kann die Grundfunktionalität benutzt, später erweitert und mit wenig Abhängigkeit
implementiert werden?
3.2.1 Pattern
3.2.1.1 Inversion of Control Pattern
Inversion of Control oder Umkehrung der Steuerung bedeutet nicht mehr, als dass gewisse
Funktionalität von aussen gesteuert wird. Dieses Prinzip kommt zum Beispiel zum Tragen, wenn mit
Events oder Delegates (Callback-Funktionen) gearbeitet wird.
Problematik Wird bei der Entwicklung von Software mit Aggregationen gearbeitet, entsteht durch die Aggregation
eine sehr enge Kopplung. Je enger diese Kopplung ist, desto schlechter für die Wartbarkeit und
Änderbarkeit.
Hier ein kleines Beispiel: namespace DependencyTestApp
{ public class KlasseA {
private KlasseB _instanzB; public KlasseA()
{ this._instanzB = new KlasseB(); }
} }
Grundlagen Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 16 von 59
Die KlasseA und die KlasseB haben hier in diesem Beispiel eine sehr enge Kopplung. Die Instanz von
KlasseB wird in der KlasseA erzeugt. Somit hat eine Änderung der KlasseB einen sehr direkten Einfluss
auf die KlasseA und alle anderen Klassen, welche eine Aggregation zu KlasseB besitzen.
Dies erschwert, wie man unschwer erkennen kann, die Änderbarkeit und Wartbarkeit.
Um diese Problematik zu umgehen, gibt es grundsätzlich zwei Patterns, welche aus dem Inversion of
Control Prinzip abgeleitet sind:
• Das Dependency Injection Pattern, wenn die Funktionalität von aussen übergeben wird.
• Das ServiceLocator Pattern, wenn der zentrale Service Locator die Funktionalität ermittelt
und zurückgibt.
3.2.1.2 Dependcy Injection Pattern
Dependcy Injection funktioniert nach dem Prinzip von Inversion of Control. Zum einen wird mit
Interfaces gearbeitet, um eine Entkopplung zur Klasse zu erreichen. Zum anderen werden die
Instanzen von aussen erzeugt und übergeben. Somit weiss die KlasseA nicht mehr, wie die KlasseB
genau funktioniert, sondern arbeitet nur gegen das Interface.
Für die Injektion von Objekten gibt es verschiedene Varianten. Das Beispiel unten zeigt eine Konstruktor-Injektion.
public class KlasseA
{ private IKlasseB _instanzB;
public KlasseA(IKlasseB instanzB) { this._instanzB = instanzB;
} }
Wenn nun zum Beispiel die KlasseB durch eine andere Variante ersetzt wird, kann dies über die
Dependency Injection gelöst werden, solange natürlich das Interface gleich bleibt.
Sehr oft werden Dependency Injection Container eingesetzt, welche das Auflösen von
Abhängigkeiten übernehmen und die entsprechenden Objekte erzeugen. Ein bekannter Container in
diesem Zusammenhang ist MEF (Managed Extensibility Framework), welches seit .NET 4.0 Bestandteil von .NET ist.
Grundlagen Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 17 von 59
class Serv iceLocator
Client Class Serv ice Locator
Serv ice 1
Serv ice 2
Serv ice 3
«use»
«instantiate»
«instantiate»
«instantiate»
3.2.1.3 Service-Locator
Eine weiter Möglichkeit, Abhängigkeiten von aussen vorzugeben, besteht darin, einen Service-
Locator zu benutzen. Bei diesem sind die vorhandenen Klassen registriert. Somit kann über diese
zentrale Stelle, anhand eines Interfaces, eine Instanz eines Objektes geholt werden. Hier ein kleines
Beispiel dazu:
3.2.1.3.1 Common-Service-Locator
Der Common-Service-Locator ist ein Opensource Projekt welches einen Wrapper für unterschiedliche
Dependency Injektion Container zur Verfügung stellt.
Abbildung 11 Common Service Locator
Abbildung 10 Funktionsweise des Service-Locators
Grundlagen Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 18 von 59
cmp Separated Interface
Infrasturcture
Component1
Client
«interface»Infrasturcture::
IKlasseB
Component1::KlasseB
Client::KlasseA
Mit dem Strategy Pattern wird der Zugriff auf den Dependency Injection Container über das Interface
IServiceLocator gekapselt. Somit kann der Dependency Injection Container ausgetauscht werden,
ohne dass die gesamte Implementierung geändert werden muss.
Wie auch in der Composite Application Library von Microsoft patterns & practices verwendet, ist der
Common Service-Locator ein guter Ansatz, um nicht komplett vom verwendeten Dependency
Injection Container abhängig zu sein. Somit ist es später möglich, den Dependency Injection
Container auszutauschen, ohne den gesamten Code zu überarbeiten. Für den Benutzer des Service-
Locators bleibt der Aufruf gleich. Nur der Service muss für den entsprechenden Dependency Injection Container angepasst werden.
3.2.1.4 Separated Interface
Wenn nun die konkrete Instanz von einem Dependency Injection Container oder einem
ServiceLocator erzeugt wird, braucht es eigentlich keine Referenz auf die Assembly mit der konkreten
Klasse. Was eine weitere Entkopplung bewirkt. Um dies zu ermöglichen kommt das Separated
Interface ins Spiel.
Um Assembly-übergreifende Abhängigkeiten zu entkoppeln, gibt es die Möglichkeit, das Interface in
der einen Assembly und die Implementation in einer anderen zu erstellen.
So muss der Klient nur die Interface Assembly kennen und nichts, ausser dem Interface, über die
Implementation wissen. Die Instanz wird dann über den ServiceLocator erstellt.
Abbildung 12 Diagramm Separated Interface
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 19 von 59
Design 4
4.1 Einleitung
Nachdem wir nun die eine oder andere Grundlage erarbeitet haben, geht es einen Schritt weiter: Es
werden für die Anforderungen konkrete Lösungen gesucht.
4.2 Einleitung Architektur
Der Prototyp, welcher im Rahmen dieser Arbeit erstellt wird, kann später nicht weiterverwendet
werden. Daher wird die Architektur der Software so aufgebaut, dass gewisse Grundfunktionalitäten
später in der aktuellen As1 Konsole und noch etwas später in einer reinen As1 .NET Konsole
übernommen und weiterentwickelt werden können. So kann verhindert werden, dass alles neu
geschrieben werden muss.
In diesem Projekt wird für das dynamische Laden von Grundfunktionalität und von Automations-
Elementen MEF (Managed Extensibility Framework) eingesetzt. Siehe auch Kapitel 3.2:
Abhängigkeiten und Erweiterbarkeit von Software-Komponenten.
Für das Instanziieren der Grundfunktionalität nach dem Inversion of Control Prinzip, wird der
Common Service Locator (siehe 3.2.1.3 Service Locator) im Zusammenhang mit MEF und Separated
Interfaces eingesetzt (3.2.1.4 Separated Interface).
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 20 von 59
4.3 System-Architektur
4.3.1 Aufteilung der Komponenten
Im Komponenten-Diagramm (Abbildung 13) wird die strukturelle Aufteilung dargestellt. Dabei
entsprechen die Komponenten je einer Assembly. Die Pakete stellen die verschiedenen Layer des
Systems dar. Dabei ist zu beachten, dass dies nicht ein klassisches Layer-Diagramm ist. Die lose
Kopplung durch den Service Locator und das dynamische Laden der Automations-Elemente führen zu einer etwas unkonventionellen Darstellung.
Im Layer Infrastructure liegen die Komponenten, auf welche alle zugreifen dürfen. Dies betrifft vor
allem die Interfaces, welche für das Benutzen der Core Services nötig sind. Das Zugreifen z.B. vom
Layer Automations-Elemente auf den Layer Core Services ist nicht erlaubt, da dadurch die lose
Kopplung der Core Services untergraben würde.
Abbildung 13 Übersicht Architektur
PcvConcept Anwendung oder Prototyp, welcher in dieser
Arbeit erstellt wird.
As1 PCV Fachmodul der aktuellen As1, in welchem die
Steuerungsvisualisierung angezeigt wird.
As1 .NET Später sollte es eine As1 .NET geben.
AutomationViewPanel Dieses Panel dient zur Kapselung für die
Weiterverwendung.
PcsDefinitions Enthält die Definitionen der Pcs-Nachrichten.
AutViewComponents Enthält die Automations-Elemente, welche
durch das AutomationEnvironment dynamisch
geladen werden.
AutViewComponentsKundeXY Kundenspezifische Automations-Elemente.
cmp System Architektur
Infrastructure
Panel
Automation-Elements
Host Core Serv ices
AutomationEnv ironment
AutomationEnv ironment.Controls
AutomationEnv ironment.InfrastructureAutomationViewPanel
AutViewComponents
PcsMessageConnectorPcsMessageConnector.Infrastructure
Pcv Concept
PcsDefinitions
Wird dynamisch durch das AutomationEnviroment geladen.
Wird durch ServiceLocator geladen.
AutViewComponentsKundeXY
As1 PCV As1 .NET
AutomationEnv ironment.Theme
Ammann.Core
Unity.Foundation
Unity.Foundation.Infrastructure
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 21 von 59
AutomationEnvironment.Controls Enthält Controls, welche für die Steuerung benutzt werden.
AutomationEnvironment.Theme In dieser Assembly befinden sich die Themes respektive die Styles welche benötigt werden.
AutomationEnvironment.Infrastructure Nach dem Separated-Interface-Prinzip stehen hier die Interfaces allen zur Verfügung.
PcsMessageConnector.Infrastructure Nach dem Separated-Interface-Prinzip stehen
hier die Interfaces allen zur Verfügung.
AutomationEnvironment Grundfunktionalität für das Laden und Anzeigen
der Automations-Elemente.
PcsMessageConnector Grundfunktionalität für das Senden und
Empfangen von Pcs-Nachrichten.
Ammann.Core Assembly der Firma Ammann Schweiz AG,
welche Basisfunktionalität enthält wie z.B. die
Klasse BindableObject, welche im
Zusammenhang mit Binding in WPF
Unterstützung bietet.
Unity.Foundation Assembly der Firma Ammann Schweiz AG,
welche Basisfunktionalität enthält wie Exception
Handling und Logging.
Diese Assembly muss später vom Infrastructure-
Bereich in den CoreService-Bereich überführt
werden; leider ist dies im Moment noch nicht
möglich.
Unity.Foundation.Infrastructure Interfaces für die Unity.Foundation.
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 22 von 59
class Automations-Element erstellen
UserControl
SurfaceElement
SurfaceAutomationElementSurfaceWindowElement
Mischer
AutomationElementViewModelBase
MischerViewModel
BindableObject
4.4 Automations-Element erstellen
Die Automations-Elemente werden mit C# und MVVM erstellt, wie dies in Kapitel 2.4 (Entscheidung,
wie Automations-Element erstellen), dargestellt wurde. Die Automations-Elemente werden als
UserControls entwickelt. Die Automations-Elemente für den Baukasten werden in der Assembly
AutViewComponents erstellt.
4.4.1 Klassen für das Erstellen eines Automations-Elementes
In Abbildung 14 wird aufgezeigt, wie das Klassendiagramm für das Automations-Element Mischer
aussieht.
UserControl Das UserControl ist eine Basis Klasse von .NET
welche zum Erstellen von eigenen Controls
verwendet werden kann. Dieses leitet vom
ContentControl ab.
SurfaceElement Basis-Element, welches auf der Visualisierung
angezeigt werden kann. Es ist verantwortlich
für das Positionieren und Verschieben. SurfaceWindowElement Dieses Element dient als Basis für ein
fensterähnliches Objekt, welches auf der
Visualisierung dargestellt werden soll. Z.B.
ein Dialog, mit welchem neue Automations-
Elemente hinzugefügt werden können.
SurfaceAutomationElement Diese Klasse dient als Basis für Automations-Elemente. Es ist verantwortlich für
Grundfunktionalität eines Automations-
Elementes.
BindableObject Basis-Klasse aus dem Namespace Ammann.Framework.Core, welche Funktionalität für das
INotifyPropertyChanged Interface, welches für das Binding mit WPF benötigt wird, bereitstellt. Somit
kann der Visualisierung mitgeteilt werden, wenn ein Property geändert hat, damit die Darstellung
aktualisiert werden kann.
AutomationElementViewModelBase Basis Klasse für das View-Model.
Mischer Nur ein Beispiel für ein Automations-Element.
Warum befindet sich das View-Model nicht in einer separaten Assembly?
Abbildung 14 Klassendiagramm Automations-Element
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 23 von 59
Abbildung 16 ItemTemplate AutomationElement
Um das MVVM Pattern ganz genau umzusetzen, müsste das ViewModel in einer separaten Assembly
sein. Somit könnte das ViewModel hinsichtlich der View sehr einfach für mehrere Technologien
benutzt werden.
Dies würde allerdings das Erstellen der Automations-Elemente erschweren, da der Code verteilt
würde.
Die weitere Frage, die sich mir stellt, ist; Auf welche andere Technologie kann einfach gewechselt
werden? Im Moment wäre dies wahrscheinlich einzig mit Silverlight möglich. Dabei gibt es aber
wiederum unterschiedliche Probleme welche das Implementieren von Code in Silverlight und WPF im
Moment nur schwer möglich machen. So wird in diesem Projekt nur eine Assembly benutzt, und bei einem Technologie-Wechsel könnten
die ViewModels dann mit etwas mehr Aufwand trotzdem übernommen und benutzt werden.
4.4.2 Item Template für Visual Studio
Durch den Umstand geschuldet, dass nun eine eigene Basis-Klasse anstelle des User Controls verwendet wird, wird das Erstellen eines Automations-Elementes wesentlich aufwändiger. Im XAML
muss anstelle vom UserControl das SurfaceAutomationElement eingetragen werden. Dies gilt auch
für den Code Behind, und das entsprechende ViewModel muss erstellt und instanziiert werden.
Daher ist es naheliegend mit dem Visual Studio SDK ein Template zu erstellen, welches das
Automations-Element anhand eines Namens
komplett erstellt.
So ist auch gewährleistet, dass keine
Flüchtigkeitsfehler auftreten und das Automations-
Element korrekt geladen werden kann.
4.4.3 Ein neues Automations-Element erstellen
Wenn ein neues Automations-Element erstellt werden
soll, kann dies über das ItemTemplate
AutomationElement sehr einfach erledigt werden.
Anhand des eingegebenen Namens werden folgende Dateien erstellt:
Abbildung 15 Add Item Template
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 24 von 59
Dabei wird im Code Behind des UserControls (AutomationElement2.xaml.cs) die Deklaration für den
Export mit MEF eingetragen (siehe Kapitel 4.5). Somit muss sich der Anwender nicht um die korrekte
Deklaration der Attribute kümmern. In unserem Beispiel sieht das in etwa so aus: [PcsSurfaceExport(typeof(AutomationElement2))]
[PartCreationPolicy(CreationPolicy.NonShared)]
public partial class AutomationElement2 : SurfaceAutomationElement
Im UserControl (AutomationElement2.xaml) wird die Instanziierung des
AutomationElement2ViewModels erstellt. Dabei wird dies je für die Laufzeit und die DesignTime
deklariert. Somit ist es möglich das DataBinding in Expression Blend über den Dialog CreateDataBinding zu erstellen, was das Vertippen, wie beim manuellen Schreiben in XAML,
verhindert.
Es können auch Design-Time-Daten dargestellt werden. Dies ermöglicht dem Designer bei der
Erstellung der grafischen Darstellung eine bessere Vorstellung, wie es später mal aussehen wird.
Nachdem das ItemTemplate AutomationElement ausgeführt wurde, kann mit dem Programmieren
der Darstellungslogik und dem Designen der grafischen Darstellung begonnen werden. Das
Automations-Element wird durch MEF, nach dem Kompilieren, automatisch für die Darstellung
geladen.
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 25 von 59
4.5 Automations-Elemente dynamisch laden
Die Automations-Elemente sollen dynamisch geladen werden; dabei kommt ein Plugin-Mechanismus
zum Tragen.
In diesem Projekt soll MEF eingesetzt werden. Dabei sollen alle Automations-Elemente aus den
Assemblies mit Namen „AutViewComponents*.dll“ im Verzeichnis der Applikation geladen werden.
Somit werden kundenspezifische Assemblies wie zum Beispiel AutViewComponentsKunde1.dll automatisch geladen.
Wie in Abbildung 17 zu sehen werden Klassen, welche ein Export-Attribut haben, von MEF exportiert
und im SurfaceElementService importiert.
AutViewComponents
Mischer
AutomationEnviroment
ImportSurfaceElementService
Export
Abbildung 17 MEF Export Import
Es wäre zum Beispiel möglich, für verschiedene Anlagen-Typen unterschiedliche Assemblies zu
erstellen. Weiter können auch kundenspezifische Assemblies geladen werden, ohne die gesamte
Anwendung neu zu kompilieren.
MEF ist Bestandteil von .NET 4.0 und in den Namespaces System.ComponentModel.Composition und
System.ComponentModel.Composition.Hosting zu finden.
DirectoryCatalog: Ermittelt Klassen mit einem Export-Attribut in Assemblies in einem angegebenen Verzeichnis.
CompositionContainer: Verwaltet die exportierten Klassen.
Export: Mit diesem Attribut wird eine Klasse für den Export mit MEF gekennzeichnet.
PartCreationPolicy: Mit diesem Attribut kann angegeben werden, ob beim Erzeugen durch MEF
jedes Mal dieselbe Instanz zurückgegeben oder jedes Mal eine neue Instanz erzeugt werden soll.
Anschliessend ein kleines Code-Beispiel, welches eine Klasse exportiert und wieder importiert.
In diesem Beispiel wird die Klasse Test mit dem Interface ITest exportiert und importiert.
Export (Z.B. AutViewComponents.dll) [Export(“Test”, typeof(ITest))]
public class Test : ITest {}
Import (Z.B. AutomationEnvironment.dll) var Catalog = new DirectoryCatalog("*AutViewComponents*.dll", ".");
_container = new CompositionContainer(Catalog); ITest test =_container.GetExport<ITest>(„Test“).Value;
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 26 von 59
Export Attribut Die Automations-Elemente werden mit dem Namen des Typs(z.B. Mischer) und mit dem Interface
ISurfaceElement exportiert. Um dies zu vereinfachen, wird ein eigenes Attribut PcsSurfaceExport
erstellt, bei dem nur der Typ übergeben werden muss; das Interface ISurfaceElement wird
automatisch verwendet.
Diese Klasse wird nun mit dem Typ ISurfaceElement und dem Namen Mischer exportiert: [PcsSurfaceExport(typeof(Mischer))] [PartCreationPolicy(CreationPolicy.NonShared)] public partial class Mischer : SurfaceAutomationElement
{
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 27 von 59
4.6 Automations-Elemente darstellen
Wie können Elemente in WPF dargestellt werden? Die Automations-Elemente müssen nach X/Y-
Koordinaten positioniert werden. In WPF gibt es dafür das Canvas Control, welches Subelemente in
X/Y-Koordinaten darstellen kann.
4.6.1 Grundsätzlicher Aufbau
Der grundsätzliche Aufbau wird so erstellt, dass die Steuerungsvisualisierung in verschiedenen Clients
benutzt werden kann. Die AutomationViewPanel.AutomationView dient in diesem Fall der
Kapselung. Diese soll später in einem ActiveX oder einem .NET Fachmodul gehostet werden können.
Das PcsCanvas stellt die Automations-Elemente dar.
Abbildung 18 Aufbau Prototyp
PcvConcept Dies ist die Anwendung resp. der Prototyp. Dieser dient nur zu
Demonstration der Funktionalität und wird nicht produktiv eingesetzt.
Der Prototyp ist in seinem Aufbau dem METRO Design Konzept
nachempfunden.
AutomationView
Dieses Panel soll später weiterverwendet werden können. Die
AutomationView stellt das PcsCanvas dar und bestimmt welche
Konfiguration geladen werden soll.
PcsCanvas
Das PcsCanvas hat als Basis ein Canvas Control. Die Verantwortung dieses
Controls ist das Darstellen der Automations-Elemente nach X/Y-
Koordinaten.
PcvConcept
AutomationView
PcsCanvas
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 28 von 59
4.6.2 Klassen für das Darstellen von Automations-Elementen
Es ist möglich, dass unterschiedliche VisualisationScreens dargestellt werden. Ein VisualisationScreen
besteht aus einer gewissen Anzahl von SurfaceElementen. Mehr dazu im Kapitel 4.7 (Dynamik der
Benutzeroberfläche).
Die Automations-Elemente werden im PcsCanvas dargestellt. Mittels DataBinding von der
AutomationView über das AutomationViewViewModel wird der aktuelle VisualisationScreen dem PcsCanvas mitgeteilt.
Die Konfiguration wird über die serialisierbaren Klassen AutomationViewConfiguration und
AutomationElementConfiguration persistent gespeichert.
Abbildung 19 Übersichts-Diagramm Automations-Elemente darstellen
AutomationElementConfiguration Diese Klasse enthält die Konfiguration eines Automations-
Elementes. Dies sind Daten wie X/Y-Position.
AutomationViewConfiguration Diese Klasse enthält eine Liste von Automations-Elementen,
welche in einer Ansicht dargestellt werden.
SurfaceElement Element welches in der Visualisierung dargestellt wird. Die
Basisklasse ist das UserControl.
VisualisationScreen Eine Darstellung mit verschiedenen SurfaceElementen
VisualisationScreenManager Dieser händelt mehrere VisualisationScreens.
AutomationView UserControl welches das PcsCanvas darstellt.
PcsCanvas Das PcsCanvas ist für das Darstellen der SurfaceElemente eines
VisualisationScreens verantwortlich.
AutomationViewViewModel View Model für Binding der AutomationView
class Automations-Elemente darstellen 2
VisualisationScreenManager
VisualisationScreen AutomationViewConfiguration
SurfaceElement
AutomationElementConfiguration
AutomationView
PcsCanv as
AutomationViewViewModel
11
1
11
1
10..1
1
0..*
1 0..1
10..*
0..1
+Current 0..1
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 29 von 59
4.6.3 Ablauf Automations-Element darstellen
Die Automations-Elemente werden dargestellt, sobald der Screen gewechselt wird. Über das Data-
Binding verknüpft wird dem PcsCanvas mit dem PropertyChanged Event mitgeteilt, dass sich der
Screen geändert hat. Anhand des VisualisationScreens werden nun alle vorhandenen
SurfaceElemente der Children-Liste hinzugefügt und positioniert - und somit dargestellt.
Damit erkannt wird, dass während des Anzeigens ein SurfaceElement hinzugefügt oder entfernt wird, wird der Event CollectionChanged auf der Liste „VisualisationScreen.SurfaceElements“ registriert.
Wird nun ein SurfaceElement hinzugefügt, wird dieser Event ausgelöst und das SurfaceElement kann
der aktuellen Darstellung hinzugefügt werden.
Abbildung 20 Sequenzdiagramm Automation-Element darstellen
4.6.4 Konfiguration in ViewModel
Beim Erstellen und Darstellen der Automations-Elemente wird mit der Basis-Klasse SurfaceElement
gearbeitet. Die AutomationElementConfiguration ist somit nur dem SurfaceElement bekannt, nicht
aber dem ViewModel. Es ist jedoch unbedingt notwendig, dass das ViewModel die Konfiguration
kennt. Als Beispiel könnte dies für die Pcs-Nachrichten-Vermittlung der Name des Automations-
Elementes für die Bezeichnung des PcsMessageTargets sein. Das Thema Pcs-Nachrichten wird im
Kapitel 4.10 genauer erläutert.
Die hier beschriebenen Klassen sind im Klassendiagramm Abbildung 14 dargestellt. Das ViewModel ist dem SurfaceAutomationElement durch den DataContext bekannt. Um nun die
Verknüpfung SurfaceAutomationElement zu AutomationElementViewModelBase erstellen zu
können, wird der DataContext auf den Typ IAutomationElementViewModelBase überprüft. Falls dies
zutrifft, kann die Referenz auf dieses Objekt gespeichert werden. Somit ist es möglich, der
AutomationElementViewModelBase die Konfiguration des Automations-Elementes mitzuteilen.
sd Automations-Element darstellen
CurrentScreen:VisualisationScreen
:PcsCanvas:VisualisationScreenManager Children:UIElementCol lection
loop foreach
[element in CurrentScreen.SurfaceElements]
ChangeScreen(string)
OnCurrentScreenChanged(DependencyObject,DependencyPropertyChangedEventArgs)
SurfaceElements() :IList<ISurfaceElement>
Chi ldern.Add(element)
Canvas.SetLeft(element,pos)
Canvas.SetTop(element,pos)
Für CollectionChanged Event registrierenListe SurfaceElements()
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 30 von 59
4.7 Dynamik der Benutzeroberfläche
Für das Verändern des Detaillierungsgrades gibt es zwei Überlegungen.
Mouse Over Effekt In jedem Automations-Element besteht die Möglichkeit, einen Mouse-
Over-Effekt zu implementieren.
Verschiedene Ansichten Ein übergeordneter Mechanismus ist das Anzeigen von verschiedenen Ansichten (VisualisationScreens). Im Prototyp kann über das Menu
zwischen den verschiedenen Ansichten umgeschaltet werden
(Übersicht, Vordosierung, Mischauftrag und Bitumen).
Was in den einzelnen Ansichten angezeigt werden soll, kann für den
Kunden konfiguriert werden.
Dabei ist es möglich, in einer gewissen Ansicht Automations-Elemente
ein- oder auszublenden oder die Darstellungsvariante eines
Automations-Elementes zu variieren. In einer Übersicht könnten zum
Beispiel übergeordnete Automations-Elemente dargestellt werden,
welche einen ganzen Anlage-Teil zusammenfassen.
In Abbildung 21 ist das Menu, mit welchem die verschiedenen
Ansichten umgeschaltet werden können, markiert.
Im Prototyp werden diese nicht konfigurierbar hinterlegt.
Für die Bezeichnung der einzelnen Ansichten (VisualisationScreens) wird
der Name im Menu benutzt.
Abbildung 21 Prototyp Menu
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 31 von 59
4.8 Design-Modus
Design-Modus bezieht sich hier auf die Laufzeit der Anwendung, wenn der Engineer die Anlage für
den Kunden einrichtet. Dabei sollen Elemente eingefügt, verschoben und benannt werden können.
Der hier gewählte Ansatz bezieht sich auf des Erweitern des Automations-Elementes. Das heisst,
wenn der Design-Modus aktiv ist und die Maus sich über einem Automations-Element befindet, wird
um das gesamte Automations-Element etwas eingeblendet.
Lookless Control Dazu wird ein Mechanismus von WPF benutzt, welcher für die Entwicklung von Custom Controls zum
Tragen kommt. Dabei wird nach dem Prinzip Lookless Control gearbeitet. Das bedeutet, das Control
hat nur die Logik implementiert. Das Aussehen wird über ein Control Template vorgegeben.
Dieses Prinzip wird nun für das SurfaceAutomationElement angewendet. Ein Control Template
bestimmt das Aussehen und im Control ist die Logik zum Beispiel für das Verschieben implementiert.
PARTS Wie kann nun das Control auf Elemente des Control Templates zugreifen? Dazu werden die so genannten PARTS benutzt. Diese PARTS sind nichts weiter als Bezeichnungen, welche im Control
Template und im Control benutzt werden. Über das TemplatePartAttribute kann bei einem Control
angegeben werden, welche PARTS von welchem Typ benötigt werden. In der Methode
OnApplyTemplate des Controls kann nun über GetTemplateChild eine Referenz auf das
entsprechende Objekt aus dem Control Template geholt werden. In Abbildung 22 ist der Aufbau
mittels Control Template zu sehen.
Abbildung 22 SurfaceAutomationElement Style
Dieser SurfaceAutomationElementStyle bewirkt nun, dass im Design-Modus und bei einem Mouse-
Over-Event ein Rahmen um das Automations-Element gezeichnet wird und auf der Seite
verschiedene Controls angezeigt werden. Durch Drücken und Zeihen am oberen Ende kann das
Element verschoben werden.
class Control Template
SurfaceElement
SurfaceAutomationElement
UserControl
Mischer
«Style»SurfaceAutomationElementStyle
«Control Template»
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 32 von 59
In der unten stehenden Abbildung ist die Darstellung des Design-Modus zu sehen.
Abbildung 23 Darstellung Design-Modus
4.8.1 Verschieben von Automations-Elementen
Um ein Automations-Element zu verschieben, werden in der Klasse SurfaceElement die Methoden des UserControls OnPreviewMouseLeftButtonDown, OnPreviewMouseMove und OnPreviewMouse-
LeftButtonUp überschrieben, damit bestimmt werden kann, ob das Element verschoben wird und
wohin es verschoben wird. Der Bereich, welcher für das Verschieben gültig ist, ist der MOVE_PART
Bereich.
4.8.2 Layer einstellen
Da die Automations-Elemente übereinander dargestellt werden können, muss es möglich sein den
Layer eines Elementes einzustellen. Das heisst, wenn ein Element unter einem anderen ist, muss es
in den Vordergrund geholt werden können.
Für den Prototyp werden nur die beiden Funktionalitäten „eine Stufe in den Vordergrund“ und „eine
Stufe in den Hintergrund“ eingebaut (Button ). Die Funktionalität „in den Vordergrund“ und „in den Hintergrund“ wird erst zu einem späteren
Zeitpunkt implementiert.
Das Verstellen des Layers wird in der Klasse SurfaceElement über Canvas.SetZIndex realisiert. Die
Verbindung Button-Drücken, um etwas auszuführen auf dem SurfaceElement, wird über ein
Command und DataBinding realisiert.
Hier zeigt als Beispiel der XAML-Code, wie das DataBinding im Template realisiert wird: Command="{Binding OneStepToFront, RelativeSource={RelativeSource TemplatedParent}}"
Als Source muss hier der TemplateParent angegeben werden, weil sich der Button im Template des
Automations-Elementes befindet.
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 33 von 59
4.8.3 Hinzufügen von Automations-Elementen
Für das Hinzufügen von Automations-Elementen ist das
SurfaceWindowElement AddSurfaceElement zuständig. Dieses kann über
den Button „Hinzufügen“ dargestellt werden. Mit Doppelklick auf ein
Element aus der Liste kann dieses hinzugefügt werden.
Was nach dem Doppelklick geschieht, ist im nachfolgenden Sequenz-
diagramm zu sehen.
Auf dem ViewModel wird über ein Command die Methode OnAddElement
aufgerufen. Auf dem aktuellen Screen wird AddElement aufgerufen. Im
VisualisationScreen werden die Konfiguration und das Element erstellt. Wird das Element in die Liste
SurfaceElements eingefügt, wird das PcsCanvas über den CollectionChanged Event informiert. Das
Element wird im Canvas dargestellt.
Abbildung 25 Sequenzdiagramm Automations-Element hinzufügen
4.8.4 Automations-Element benennen
Wie in Abbildung 23 zu sehen, wird ein Text-Feld angezeigt, womit der Name geändert werden kann.
Wird eine Eingabe gemacht, wird über DataBinding die AutomationViewConfiguration geändert.
sd Automations-Element hinzufügen
:AddSurfaceElementViewModel
User
:VisualisationScreen :Configuration:AutomationViewConfiguration :PcsCanvas
OnAddElement(TypeName)
AddElement(string, string, int, int)
AddConfiguration(string, string, int, int) :IAutomationElementConfiguration
AddAndCreateSurfaceElement(configuration)
SurfaceElements_CollectionChanged(object, System.Collections.Specialized.NotifyCollectionChangedEventArgs)
Abbildung 24 Dialog AddSurfaceElement
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 34 von 59
4.8.5 Design-Modus ein-/ausschalten
Wird der Design Modus ein- oder ausgeschaltet, wird über ein Command auf dem MainViewModel
die Methode OnSwitchDesignMode aufgerufen. Diese setzt auf dem CurrentScreen das Property
IsInDesignMode. Und es wird bei allen SurfaceElementen der Design-Modus umgeschaltet.
Abbildung 26 Sequenzdiagramm Design-Modus
4.8.6 Darstellungsvarianten
Automations-Elemente können in verschiedenen Varianten benutzt werden. Dazu müssen über
einen Mechanismus mehrere Darstellungsvarianten erstellt, und anschliessend umgeschaltet werden
können. Die Darstellungsvarianten müssen nur im Design-Modus umgeschaltet werden können.
Visual States Seit .NET 4.0 stehen ausser in Silverlight auch in WPF die Visual
States zur Verfügung.
In Abbildung 27 sind die verschiedenen Visual States eines Buttons zu sehen. Diese States werden von WPF verwaltet.
Wenn z.B. die Maus über dem Button ist, wird automatisch in
den MouseOverState gewechselt. Visual State Groups wie im
Beispiel CommonStates sind Kategorien für die Visual States.
Gleichzeitig kann in jeder State Group genau ein Visual State
aktiv sein.
Es ist auch möglich, eigene solche Visual States zu erstellen.
Diese können über den VisualStateManager abgefragt und je
nachdem gesetzt werden. Diese Visual States sind bestens dazu geeignet, verschiedene Darstellungsvarianten grafisch zu
erstellen.
Konzept Es wird eine eigene State Group „Variant“ erstellt. In dieser können in Expression Blend eigene
Anzeige-Varianten (Visual States) hinzugefügt werden. Über den VisualStateManager werden diese in
der Klasse SurfaceAutomationElement abgefragt und zur Auswahl in einer Combobox dargestellt.
sd Design Modus einschalten
User
:MainWindowViewModel CurrentScreen:VisualisationScreen
OnSwitchDesignMode()
SetIsInDesignMode()
SetDesignModeForElements()
Abbildung 27 Visual States
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 35 von 59
Wird ein Visual State ausgewählt, wird dieser über den VisualStateManager gesetzt. Der eingestellte
Visual State wird in der Konfiguration des entsprechenden Automations-Elements gespeichert.
Laden der vorhandenen Visual States Damit die Visual States nicht bei jedem Start der Applikation automatisch geladen werden, werden
sie erst geladen, wenn es nötig ist. Das heisst: Wenn zum ersten Mal im Design-Modus die Maus über
ein Element fährt und das Template eingeblendet wird, werden alle vorhandenen Bezeichnungen der
Visual State dieses Automations-Elementes geladen. Die Bezeichnungen der Visual States werden in
einer Combobox dargestellt. Die Verknüpfung SurfaceAutomationElement und Combobox geschieht über DataBinding.
Wie können die vorhandenen Visual States abgefragt werden?
Auf dem VisualStateManager können über die Methode GetVisualStateGroups(FrameworkElement
obj) alle Visual Groups innerhalb eines FrameworkElements abgefragt werden. Deshalb gibt es in den
Automations-Elementen im XAML ein Grid mit der Bezeichnung „LayoutRoot“; in diesem wird die
Visual Group „Variant“ erstellt, in welcher dann die Visual States eingefügt werden. So kann nach
dem Grid „LayoutRoot“ gesucht und dieses dem VisualStateManager beim Aufruf übergeben
werden. Wird die Visual Group „Variant“ gefunden, können auf dieser die vorhandenen Visual States
abgefragt werden.
Darstellungsvariante umschalten Über die Methode VisualStateManager.GoToElementState(
FrameworkElement stateGroupsRoot, String stateName, Boolean
useTransitions) kann ein Visual State gesetzt werden. Auch hier muss ein
FrameworkElement übergeben werden. Dies entspricht wieder dem
„LayoutRoot“ Grid.
Abbildung 28 Darstellungsvarianten umschalten
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 36 von 59
4.9 Kundenspezifische Automations-Elemente erstellen
In der Ammann Schweiz AG gibt es für Automations-Elemente Erweiterungen, die nicht in den
Baukasten einfliessen sollen, da sie nur für einen Kunden entwickelt werden. Dabei ist es möglich,
dass ein gesamtes Automations-Element neu erstellt oder ein vorhandenes Automations-Element
angepasst wird.
4.9.1 Kundenspezifisches Automations-Element neu erstellen
Dies kann durch Hinzufügen einer zusätzlichen Assembly welche durch MEF dynamisch geladen wird,
sehr einfach gemacht werden. Dazu wird eine kundenspezifische Assembly (z.B.
„AutViewComponentsKundeX.dll“) erstellt, welche die Automations-Elemente für diesen Kunden
enthält. Diese Assembly wird durch MEF automatisch geladen, und somit stehen die neuen Automations-Elemente zur Verfügung.
4.9.2 Vorhandenes Automations-Element anpassen
Dies ist ein Fall, der sehr selten auftritt. Es muss aber die Möglichkeit geben, Automations-Elemente kundenspezifisch anzupassen.
Bei dieser Variante ist die Schwierigkeit, dass XAML nicht vererbbar ist. Es gibt für die visuelle
Darstellung nur die folgenden beiden Varianten:
• Neue Darstellung – resp. Kopieren des XAML-Codes
• Vorhandenes Automations-Element in Neues einfügen
Die Anzeigelogik resp. das ViewModel kann vererbt werden. Daher kann die Anzeigelogik sehr einfach erweitert oder angepasst werden.
Wenn die Darstellung (XAML) angepasst werden muss, sollte für jeden Fall separat untersucht
werden, welche Variante am meisten Sinn macht.
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 37 von 59
4.10 Pcs-Nachrichten
Infolge des Entscheids für eine reinen .NET Lösung stellt sich natürlich die Frage: Wie können Pcs-
Nachrichten gesendet und empfangen werden? Die Pcs-Nachrichten werden als C++ Structs binär
versendet und empfangen. Daher können diese nicht einfach in .NET empfangen und benutzt
werden.
Wie sollen Automations-Elemente und je nachdem auch andere Objekte Pcs-Nachrichten empfangen können? Für die Implementation sollte darauf geachtet werden, dass für den Empfang der Pcs-
Nachrichten keine Vererbung nötig ist, sondern dass diese Funktionalität über eine Aggregation
benutzt werden kann.
4.10.1 Ansi C++ Structs in .NET benutzen
Um Datenstrukturen aus C++ in .NET zu benutzen, gibt es das so genannte Marshalling. Dabei werden
die Structs für .NET umgewandelt. Damit dies klappt, müssen die Structs auch in C# definiert werde.
C# Marshalling Für die Umwandlung von nichtverwalteten Daten in verwaltete und umgekehrt stellt die Klasse
Marshal Methoden zur Verfügung. Dabei wird je ein Heap-Speicher für die verwalteten und einer für
die nichtverwalteten verwendet.
Die C++ Strukturen sind in C# nicht bekannt, daher müssen diese für C# auch definiert werden. Weil
in C# Structs auf dem Stack angelegt werden, wird für diesen Anwendungsfall nicht der Typ Struct, sondern der Typ Klasse verwendet. Klassen sind Referenz-Typen und werden auf dem Heap-Speicher
angelegt. Die Speichergrösse des Stacks ist sehr begrenzt. Für die Umwandlung spielt es keine Rolle
ob als Typ eine Struktur oder eine Klasse verwendet wird.
Hier ein kleines Beispiel, wie die Definition einer Klasse in C++ und C# aussehen könnte.
C++ Struktur #pragma pack(push, MessageDecl, 1) typedef struct { EPcsPrivateMsgType MsgType;
float fValue1;
float fValue2;
} STestMsg #pragma pack(pop, MessageDecl)
C# Klasse [StructLayout(LayoutKind.Sequential, Pack = 1, CharSet=CharSet.Unicode)] [Serializable]
public class TestMsg { public int Type;
public float fValue1; public float fValue2; }
Über das Marshalling können nun diese beiden Klassen von der einen in die andere und umgekehrt
umgewandelt werden.
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 38 von 59
4.10.2 Umwandeln der vorhandenen C++ Nachrichten
Sehr viele Nachrichten sind im vorhandenen System bereits definiert. Wie können diese
umgewandelt und benutzt werden?
Momentan sind die C++ Structs (Contracts) für die Kommunikation in 2 Libraries (RTC und
Visualisierung MFC) verteilt. Die Datenkontrakte sind somit redundant im System vorhanden.
Diese C++ Structs (Contracts) müssen zentral in einer Library zusammengeführt werden. Somit
können diese an zentraler Stelle umgewandelt und für C# zur Verfügung gestellt werden. Dies sollte
über Code-Generierung automatisiert werden. Die Pcs-Nachrichten könnten für den RTC nach wie
vor in C++ Structs definiert werden, und diese würden dann automatisch in C# Klassen umgewandelt.
Für die Umwandlung könnte zum Beispiel T4 eingesetzt werden. Das Zusammenführen der C++
Structs und die Code-Generierung sind nicht Bestandteil der Master Thesis. Für den Prototyp werden
Pcs-Nachrichten manuell erstellt.
In Abbildung 29 wird das Zusammenführen der C++ Structs grafisch dargestellt.
Abbildung 29 Pcs-Nachrichten Contracts
4.10.3 Kommunikation mit dem PcsMessageDispatcher
Die Pcs-Nachrichten werden über den PcsMessageDispatcher gesendet und empfangen. Um mit dem
PcsMessageDispatcher zu kommunizieren, gibt es ein COM-Objekt PcsMessageDispatcherLib,
welches als Referenz in .NET verwendet werden kann. Darin enthalten sind, die Klasse
PcsMsgDispatchManager und das Interface IPcsMailbox, welche für die Kommunikation benötigt
werden.
Über den PcsMsgDispatchManager kann eine Verbindung registriert und getrennt werden. Das
Interface IPcsMailbox kommt für eine Verbindung gleich zweimal zum Tragen: einerseits für das
Empfangen von Nachrichten (wird bei RegisterConnection übergeben) und anderseits für das Senden von Nachrichten (Rückgabe Wert von RegisterConnection).
Hier ein Code-Beispiel, wie eine Verbindung zum PcsMessageDispatcher aufgebaut wird. „This“
entspricht hier dem PcsPortNet.
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 39 von 59
_sendBox = _pcsMsgDispatcherManager.RegisterConnection((this as PCSMESSAGED
ISPATCHERLib.IPcsMailbox), ref PortName, bIsQueuing ? 1 : 0);
4.10.4 Klassen
In dem nachfolgenden Klassendiagramm wird der Aufbau der Nachrichtenvermittlung dargestellt.
Dabei ist, grafisch hervorgehoben, die spezifische Implementation für den heutigen
PcsMessageDispatcher zu sehen. Diese Trennung ist bewusst so gewählt, da sich ja später etwas an
der Kommunikations-Schnittstelle verändern könnte. Und so lassen sich Änderungen an der
Schnittstelle zum PcsMessageDispatcher mit einer anderen PcsPortNet-Klasse relativ einfach
umsetzen.
Abbildung 30 Übersichts-Klassendiagramm Pcs-Nachrichten
PcsMessageService Der Service stellt die Funktionalität für alle zur Verfügung. Das heisst, es
kann sich jeder für eine Nachricht registrieren oder eine Nachricht senden. Voraussetzung dafür ist natürlich, dass das entsprechende Enum
und der Typ bekannt sind.
PcsMessageTarget Ein PcsMessageTarget entspricht einer Nachrichten-Einheit. Das heisst,
diese entspricht einer Adresse (z.B. Vis10.Mischer) und kann
entsprechend der Enum-Definition Nachrichten (PcsMessage) empfangen.
Generic E steht für das Enum, welches die privaten Nachrichten des
class PcsNachrichten
Spezifische Implementation für den heutigen PcsMessageDispatcher
ET
PcsMessage
E
PcsMessageTargetPcsMessageServ ice
+ RegisterMessageTarget(string) : IPcsMessageTarget<E>+ Send(string, string, object) : void
PcsPortNet
PCSMESSAGEDISPATCHERLib::IPcsMailbox
+ Info: string
+ Send(string) : void
PCSMESSAGEDISPATCHERLib::PcsMsgDispatchManager
+ RegisterConnection(IPcsMailbox, string, bool) : IPcsMailbox+ UnregisterConnection(IPcsMailbox) : void
PcsMessageReceiv eData
«use»
«use»
1
*«use»
1
1
1 *
1
+_sendBox 1
1
1
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 40 von 59
Elements enthält.
PcsMessage Diese entspricht einer einzelnen Nachricht. Das übergeordnete Element
(z.B. Automations-Element) kann sich über einen Event für den Empfang einer entsprechenden Nachricht registrieren.
Generic E steht für das Enum, welches die privaten Nachrichten des
Elements enthält.
Generic T steht für den Typ der Nachricht, welcher empfangen wird.
PcsPortNet Dieser kapselt das COM-Objekt, welches die Nachrichten über den
PcsMessageDispatcher empfängt und sendet.
Der PcsMessageService registriert sich über einen Event, damit er alle
Nachrichten empfangen, und entsprechend der Adresse weiter-leiten
kann.
PcsMessageReceiveData Diese Daten-Klasse wird für die asynchrone Abarbeitung der Pcs-
Nachrichten nach dem Empfangen verwendet. Darin werden die Daten
einer Pcs-Nachricht zwischengespeichert.
4.10.5 Registrierung für den Empfang einer Pcs-Nachricht
Die Registrierung für den Empfang einer Pcs-Nachricht wird über das PcsMessageTarget erstellt. Der
Typ der zu empfangenden Nachricht muss auch registriert werden, da nur das Automations-Element
diesen kennt. Auf der Pcs-Nachricht selber gibt es einen Event, welcher ausgeführt wird, sobald eine
Nachricht empfangen wurde.
Hier ein Beispiel, wie die Registrierung für das Empfangen einer Nachricht in einem Automations-Element erstellt werden kann:
_messageTarget.RegisterMessage<SMsgWaageWeighing>(EPcsPrivateMsgType.eWaageWeighing).ReceiveMessage += new EventHandler<PcsMsgRevieveTypeEventArgs<SMsgWaageWeighing>>(TestViewModel_ReceiveMessage);
Damit die Events auf jeden Fall deregistriert werden, wird ein Weak Event Pattern eingesetzt.
4.10.6 Asynchrone Verarbeitung der empfangenen Pcs-Nachrichten
Wenn der Event ReceiveMessage in einem Automations-Element verarbeitet wird, wird meistens
etwas an der Darstellung verändert. Deshalb muss dieser Event im Gui-Thread ausgeführt werden,
damit nicht in jedem Automations-Element ein Thread-Wechsel gemacht werden muss. Weiter ist
neben dem grafischen Darstellen das Marshalling eine relativ zeitintensive Operation.
Aus diesen Überlegungen ist die
Abbildung 31 entstanden.
Der 1. Thread ist durch das COM-
Objekt des MessageDispatchers
gegeben.
Der 2. Thread ist ausschliesslich für
die Umwandlung der Pcs-Nachricht in
C# zuständig.
Im 3. Thread wird der Event ausgeführt, was über einen
DispatcherTimer im Gui-Thread
geschieht.
Abbildung 31 Empfangene Pcs-Nachricht verarbeiten
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 41 von 59
4.10.7 Pcs-Nachricht empfangen und verarbeiten
Angesichts dessen, dass die Verarbeitung in drei Schritten geschieht, wird der Ablauf auch in diese
Teile aufgeteilt.
Pcs-Nachricht empfangen Wird eine Pcs-Nachricht empfangen, wird der Typ (int ID der Nachricht) ermittelt, damit sie korrekt
zugeordnet werden kann. Die Pcs-Nachricht wird in den Queue abgelegt.
Abbildung 32 Sequenzdiagramm Pcs-Nachricht empfangen
Pcs-Nachricht Marshalling Die empfangene Pcs-Nachricht wird nun aus dem Queue geholt, über das PcsMessageTarget der
richtigen Pcs-Message weitergegeben und umgewandelt. Beim Registrieren wurde der Pcs-Message
die Klasse, welche für das Marshalling benötigt wird, bereits mitgeteilt.
Damit beim nächsten Verarbeitungsschritt die Pcs-Message nicht noch einmal gesucht werden muss,
wird in der pcsMsgData (PcsMessageReceiveData) eine Referenz der Klasse Pcs-Message gespeichert.
Abbildung 33 Sequenzdiagramm Pcs-Nachricht marshalling
sd PcsNachrichtEmpfangen
PcsMessageDispatcher :PcsMessageService:PcsPortNet :Marshaller _pcsMessageQueueReceived:ConcurrentQueue
MsgTyp ermitteln
PCSMESSAGEDISPATCHERLib.IPcsMailbox.Send(msgData)
RawDeserialize(byte[], int, Type) :object
_portNet_ReceiveMessage(sender, e)
Enqueue(pcsMsgData)
sd PcsNachrichtMarshal
:PcsMessageService _pcsMessageQueueReceived:ConcurrentQueue :PcsMessageTarget :PcsMessage :Marshaller _pcsMessageQueue:ConcurrentQueue
Thread
loop while
[while(!ThreadAbort)]
loop while
[while ((_pcsMessageQueueReceived.Count() > 0) && (workingTimeStopwatch.ElapsedMill iseconds < 800) && (!ThreadAbort))]
DoMarshallRawPcsMessages()
TryDequeue(pcsMsgData)
DoWorkMarshalPcsMsg(pcsMsgData)
DoMarshalPcsMessage(pcsMsgData)
DoMarshalPcsMessage(pcsMsgData)
RawDeserialize(byte[], int, Type) :object
Enqueue(pcsMsgData)
Thread.Sleep(4)
Design Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 42 von 59
Pcs-Nachricht Event ausführen Beim Publizieren der Pcs-Nachricht werden für alle in der Liste pcsMsgData.PcsMessages
gespeicherten Objekte DoPublishPcsMessage aufgerufen. Die Pcs-Message führt danach den Event
aus und dem Automations-Element wird die Pcs-Nachricht mitgeteilt.
Abbildung 34 Sequenzdiagramm Event ausführen
sd PcsNachricht Event
_pcsMessageQueue:ConcurrentQueue:PcsMessageService :PcsMessage :DasElementViewModel
Timer
loop while
[while ((_pcsMessageQueue.Count > 0) && (timeOnExecute.ElapsedMill iseconds < 120))]
loop pcsMsgData.PcsMessages
[foreach pcsMsgData.PcsMessages]
_Timer_ExecutePcsMsgTargetEvent(sender, e)
TryDequeue(pcsMsgData)
DoPublishPcsMessage(pcsMsgData)
DasElementViewModel_ReceiveMessage(sender, e)
Implementation Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 43 von 59
Implementation 5
5.1 Einleitung
In diesem Kapitel werden gewisse Teile aus der Entwicklung des Prototyps speziell hervorgehoben.
Im Zusammenhang mit den Konzepten aus dem vorherigen Kapitel entsteht ein Gesamtbild über die
Funktionsweise des Prototyps.
5.2 Allgemein
5.2.1 Exception Handling und Logging
Das Logging und das Exception Handling wird durch die Ammann Schweiz AG vorgegeben.
Exceptions Dazu gibt es bereits die Funktionalität in der Ammann.Unity.Foundation Library.
Für das Exception Handling gibt es die ExceptionPolicy-Klasse, welche das Exception Handling
zentral löst. Dabei gibt es zwei Kategorien von Exception Handling, welche über die Konfiguration
App.Config eingstellt werden können. PolicyNames.Global
Diese Exceptions werden an dieser Stelle nur ins Logfile geschrieben
und danach weitergeworfen. Dies ist vor allem für Basis Libraries
gedacht und soll später bei der Fehlersuche helfen. PolicyNames.Notify Dieses Exceptions werden für den Benutzer sichtbar dargestellt.
Ein Exception Handling, welches dem Benutzer eine Meldung ausgeben soll, könnte so aussehen: catch (System.Exception ex)
{ if (ExceptionPolicy.HandleException(ex, PolicyNames.Notify)) throw;
}
Abbildung 35 Prototyp
Implementation Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 44 von 59
Logging Für das Logging wird durch die Ammann.Unity.Foundation auch die Funktionalität zur Verfügung
gestellt. Dabei können Aufzeichnungen über das Interface ILogger gemacht werden. ServiceLocator.Current.GetInstance<ILogger>().Log("Text…", LogCategory.Info);
Welche Log-Kategorien aufgezeichnet werden sollen, wird wiederum über die Konfiguration des
App.Config eingestellt. Es kann auch eingestellt werden, wohin die Daten gespeichert werden sollen (Datenbank oder Datei).
5.2.2 Unit Tests
Das Hauptaugenmerk bei diesem Prototyp liegt auf dem Überprüfen der Machbarkeit. Daher werden
Unit Tests nur an ausgewählten Stellen eingesetzt. Eine gewisse prozentuale Abdeckung ist nicht
nötig.
Zum Schreiben der Unit Tests werden das Visual Studio und das Moq Framework eingesetzt.
5.3 Initialisieren der Anwendung
Initialisieren der Applikation:
• Dabei wird MEF (Managed Extensibility Framework) mittels Catalog und Container
initialisiert.
• Weiter wird der ServiceLocator initialisert. Dazu muss der Methode SetLocatorProvider ein
Delegate mit dem Rückgabewert IServiceLocator übergeben werden.
ServiceLocator.SetLocatorProvider(() => adapter);
• Weiter werden beim Start bereits alle Darstellungen (Screens) geladen, damit nach dem Start
der Anwendung eine flüssige Bedienung möglich ist.
Die spezifische Initialisierung wird parallel über einen Threading.Tasks.Task ausgeführt, damit während dieser Zeit ein SplashScreen angezeigt werden kann und, falls vorhanden, mehrere CPU
Cores benutzt werden können.
5.4 Gui Design Prototyp
Da der Prototyp nicht direkt weiterverwendet wird, haben wir uns dazu entschlossen, designmässig
etwas Neues auszuprobieren. Microsoft promotet momentan das aus Windows Phone 7 bekannte
Metro Design. Dieser Namen wurde gewählt weil, die Grundideen an die Metro-Eisenbahn-
Signalisierung angelehnt sind. Mit der Bahn reisen täglich sehr viele Leute, und daher müssen die
Anzeigen sehr aussagekräftig und für jeden klar verständlich sein.
Für Microsoft heisst Metro: simple. clean. modern.
Testen der Anforderungen Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 45 von 59
Testen der Anforderungen 6
6.1 Anforderungen
Welche Anforderungen realisiert wurden ist in der nachfolgenden Liste beschrieben. Die Punkte ohne
Nummer unten auf der Liste wurden zusätzlich realisiert.
6.2 Code Analyse
Es wurde eine Code-Analyse-Regel überschrieben, ansonsten gibt es keine Meldungen. Für die Code-
Analyse wird einzig die Meldung CA2214:DoNotCallOverridableMethodsInConstructors in der Klasse AutomationElementViewModelBase unterdrückt. Die überschreibbare Methode InitDesingTimeData
wird nur für Expression Blend und nicht zur Laufzeit aufgerufen.
1 muss Pcs-Nachrichten empfangen
2 muss Nach empfangen Pcs-Nachricht bereitstellen
3 muss Pcs-Nachrichten senden
4 muss Vor senden Pcs-Nachricht Format anpassen
5 muss Automations-Element erstellen
6 muss Darstellungslogik programmieren
7 muss Interaktion mit Benutzeroberfläche
8 soll Verschiedene Darstellungsvarianten eines Automations-Elementes erstellen
9 soll Darstellungsvarianten umschalten
10 soll Kundenspezifisches Automations-Element neu erstellen
11 soll Automtions-Element kundenspezifisch anpassen
15 muss Automations-Elemente anzeigen
16 soll Layer einstellen
17 kann Im Design-Modus: Automations-Element einfügen
18 kann Design Modus ein-/ausschalten
19 kann Im Design-Modus: Automations-Elemente benennen
20 kann Im Design-Modus: Automations-Elemente verschieben
21 kann Avo Control erstellen
22 kann Avo Control: Pcs-Nachrichten senden und empfangen
24 kann Fehlerzustand eines Automations-Elementes
25 kann Dynamik der Benutzeroberfläche
26 muss Unabhängiger .NET Prototyp
27 kann Neue .NET Visualisierung in vorhandener Applikation
28 as1 mit .NET
Shell erstellen
Nutzung Exception Handling von Ammann Schweiz AG
Nutzung Logging von Ammann Schweiz AG
Metro Design
Item Template für das Erstellen von Automations-Elementen
Automations-Elemente: Speichern der Konfiguration
Performance Tests auf Kundensystem durchführen
Testen der Anforderungen Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 46 von 59
6.3 Abnahmekriterien
Die Abnahmekritieren werden hier wie im Pflichtenheft beschrieben durchgeführt. Vielen Dank für
die Unterstützung, durch die Ammann Schweiz AG, bei der Waagen-Grafik.
Pcs-Nachrichten senden / empfangen (2.4.1.1) Ist durch Abnahmekriterium 2.4.2.1 erfüllt.
Automations-Element erstellen (2.4.2.1) Über das Item Template wird ein neues Automations-Element mit dem Namen „Waage“ erstellt.
Die Funktionalität „Gewichtswert anzeigen“ wird über den PcsMessageTestClient gelöst, welcher auf
Anfrage einen Gewichtswert liefert. Dieser Wert wird bei jeder Abfrage hochgezählt. Im
Automations-Element wird über einen Timer zyklisch der Gewichtswert angefragt und über den
Eventhandler und ein Property über DataBinding dargestellt.
Abbildung 36 Sequenzdiagramm Abnahmekriterium
Für das Testen der Interaktion, werden ein Button und ein Text-Feld angezeigt.
Button Click…
Verschiedene Varianten eines Automations-Elementes erstellen(2.4.2.2) Die 2. Darstellungsvariante kann im Design-Modus eingeschaltet werden.
Kundenspezifisches Automations-Element erstellen (2.4.2.3)
• In einer separaten Assembly wird ein neues Automations-Element erstellt.
• Weiter wird in dieser Assembly die Waage kundenspezifisch erweitert. Dazu wird das
ViewModel vererbt und die XAML Darstellung kopiert und erweitert.
Automations-Elemente anzeigen (2.4.3.1) Ist durch Abnahmekriterium 2.4.2.1 erfüllt.
sd PcsNachrichten
PcsMessageTestClient PcvConcept
SMsgWaageWeighingRequest()
SMsgWaageWeighing()
Testen der Anforderungen Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 47 von 59
Automations-Elemente einfügen (2.4.3.2) Im Prototyp kann über die Schaltfläche Hinzufügen im Design-Modus die Toolbox mit den
vorhandenen Automations-Elementen hinzugefügt werden. Mittels Doppelklick kann ein
Automations-Element eingefügt werden.
Automations-Elemente verschieben (2.4.3.3) Im Design-Modus (Schaltfläche Design) kann, wenn sich die Maus über einem Element befindet, am
oberen Balken das Element herumgezogen werden.
Avo Control erstellen (2.4.3.4) Diese Anforderung wurde nicht implementiert.
Automations-Element Fehlerzustand anzeigen (2.4.3.5) Diese Anforderung wurde nicht implementiert.
Dynamik der Benutzeroberfläche (2.4.3.6) Diese Anforderung wurde gleich zwei Mal realisiert. Die erste Variante beinhaltet, den
VisualisationScreen umzuschalten. Für die zweite wurde im Automations-Element WaageKunde ein Text-Feld hinzugefügt, welches nur eingeblendet wird, wenn sich die Maus über diesem
Automations-Element befindet.
6.4 Unit Tests
Unit Tests wurden nicht überall eingesetzt. Da es sich hier um einen Prototyp hantelt, wurden Unit Tests nur dort eingesetzt, wo es sich anbot. Das Testen der grafischen Elemente, wie dss
SurfaceElementes, konnte durch Unit Tests nur schwer abgedeckt werden. Allerdings war es bei der
Pcs-Nachrichten-Vermittlung sehr praktisch, die einzelnen Stufen der Verarbeitung mittels Unit Tests
zu implementieren.
Testen der Anforderungen Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 48 von 59
6.5 Performance
Testsystem:
6.5.1 WPF
Abbildung 37 WPF Performance Tool
Tests werden auf einem AM6 Rechner (dies ist das aktuelle System, welches verkauft wird)
ausgeführt. Die Testresultate werden aus dem Mittel von 6 Messungen ermittelt:
Erstellen von UserControls
100 Stück 82ms
1000 Stück 831ms
5000 Stück 4079ms
Erstellen von ContentControls
100 Stück 86ms
1000 Stück 782ms
Testen der Anforderungen Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 49 von 59
5000 Stück 3888ms
Verschachteln von Elementen (Stackpanel + Button)
100 x Verschachtelt OK
775 x Verschachtelt OK
800 x Verschachtelt Stackoverflow
Property Changed jedes Element alle 200ms eine Änderung
100 Stück 3% CPU Leistung
500 Stück 21% CPU Leistung
1000 Stück 53% CPU Leistung
1200 Stück 59 % CPU Leistung
DependencyProperty jedes Element alle 200ms eine Änderung
100 Stück 3% CPU Leistung
500 Stück 25% CPU Leistung
1000 Stück 54% CPU Leistung
1200 Stück 61% CPU Leistung
6.5.2 Pcs-Nachrichten empfangen und anzeigen
Für einen möglichst realen Test werden 149 Automations-Elemente in der Visualisierung erstellt,
welche eine Pcs-Nachricht mit einer hochzählenden Nummer empfangen. Diese Nummer wird auf
der Visualisierung dargestellt. Die Pcs-Nachrichten werden durch ein Test-Tool gesendet. Während
des Tests werden unterschiedlich viele Pcs-Nachrichten gesendet und die CPU-Auslastung wird
überprüft.
596 Nachrichten / s 5% CPU Leistung
1043 Nachrichten / s 8% CPU Leistung
2235 Nachrichten / s 10% CPU Leistung
4491 Nachrichten / s 14% CPU Leistung
Abgesehen vom Start der Anlage, werden während einer Produktion zwischen 200 – 400 Pcs-
Nachrichten pro Sekunde empfangen. Das Senden von Pcs-Nachrichten fällt bei der Visualisierung
nicht ins Gewicht. Dadurch sollte die Pcs-Nachrichten-Vermittlung die Performance-Anforderungen
bei weitem erfüllen.
Fazit Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 50 von 59
Fazit 7
7.1 Was wurde erreicht?
Anhand des Prototyps ist ersichtlich, dass es technisch möglich ist, die Steuerungsvisualisierung der
Firma Ammann Schweiz AG mit WPF zu realisieren. Pcs-Nachrichten können empfangen und
gesendet werden. Automations-Elemente können erstellt und dargestellt werden.
Ob das Projekt später realisiert wird, hängt natürlich noch von anderen Aspekten ab: Lohnt sich der Aufwand? Die neue Technologie bringt viele Vorteile, wie zum Beispiel das Erstellen von Automations-
Elementen mit einem grafischen Designer Tool. Auch hinsichtlich Usability bringt WPF sehr viele
Vorteile mit sich, wie zum Beispiel die Animationen, welche in Expression Blend sehr einfach erstellt
werden können.
Andererseits ist natürlich der Aufwand, um alle vorhandenen Automations-Elemente neu in WPF zu
erstellen, enorm. Ein weiterer Aspekt, der hier auch betrachtet werden muss, ist: Wie lange
unterstützt Microsoft MFC noch? Spätestens dann, wenn dies nicht mehr der Fall ist, muss ein
Wechsel gemacht werden.
Wie werden die Engineers geschult? WPF und .NET ist für die meisten Engineers neu, daher müssen diese eine Ausbildung oder Schulung
in dieser Technologie erhalten.
Umsetzung schrittweise oder Big Bang? Eine Umstellung auf die neue Technologie in einem Schritt ist fast nicht möglich, weil dann alle
Automations-Elemente auf einmal umgestellt werden müssten. Das nimmt natürlich eine gewisse
Zeit in Anspruch. Daher wäre wahrscheinlich eine schrittweise Umstellung sinnvoller. Somit können
neue Automations-Elemente, welche in WPF entwickelt werden, relativ früh eingesetzt werden.
Dabei können Erfahrungen für die weiteren Entwicklungen gesammelt werden. Dies setzt natürlich
voraus, dass die WPF-Automations-Elemente in der jetzigen Steuerungsvisualisierung mit MFC
dargestellt werden können.
7.2 Wie geht es weiter?
Als nächster Schritt steht ganz klar der Entscheid, ob WPF für die Steuerungsvisualisierung eingesetzt
wird, im Vordergrund. Weiter müsste dann ein Projektplan für das weitere Vorgehen erarbeitet werden. Dabei bräuchte es ein Grundkonzept für das grafische Design, und es müsste bestimmt
werden welche Automations-Elemente in einer ersten Iteration neu erstellt würden.
7.3 Erfahrungen
In der Master-Thesis-Zeit habe ich sehr viel gelernt; hier einige Gedanken dazu.
Erfahrungen bei der Entscheidung, wie Automations-Elemente erstellt werden Ein wesentlicher Punkt dieser Master-Thesis war ja das Erarbeiten, wie die Automations-Elemente
erstellt werden. Dies ist sehr wichtig, weil, wenn die Framework-Funktionalität besteht, sehr viel Zeit
in die Entwicklung der Automations-Elemente investiert wird. Das Arbeiten mit der Präferenz-Matrix
und der Nutzwert-Analyse hat sich aus meiner Sicht sehr gelohnt, da nun dieser Entscheid sehr genau
nachvollzogen werden kann.
Fazit Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 51 von 59
Erfahrungen WPF Für mich war diese Arbeit das erste etwas grössere WPF-Projekt. Ich arbeite sonst eigentlich nur mit
C++ und MFC. Es gibt doch einige neue Konzepte, welche bei WPF benutzt werden.
Die Möglichkeiten, welche WPF bietet, sind für mich beeindruckend. Gerade die Bereiche mit den
Custom Controls und Control Template haben aus meiner Sicht sehr viel Potenzial. Auf WPF möchte
ich nicht mehr verzichten müssen. Ich bin mir aber bewusst, dass ich mit meinem momentanen
Wissensstand nur an der Oberfläche gekratzt und noch sehr, sehr viel zu lernen habe.
Erfahrungen MEF Der Einsatz von MEF hat sich aus meiner Sicht absolut gelohnt, sei es für den Einsatz beim
CommonServiceLocator oder das Laden der Automations-Elemente. Und da MEF glücklicherweise
seit .NET 4.0 Bestandteil des .NET Frameworks ist, denke ich dass es auch für Projekte mit einem
etwas längeren Zeithorizont eingesetzt werden kann.
Erfahrungen Service Locator Ob sich der Einsatz des Service Locators gelohnt hat, ist im jetzigen Augenblick schwierig zu
beurteilen. Für die Implementation des Prototyps wäre er ja eigentlich nicht notwendig gewesen.
Für den weiteren Projektverlauf, denke ich aber, macht es absolut Sinn, die Core Service über das Separated Interface mittels Service Locator zu benutzen. Dadurch wird die Abhängigkeit von MEF
minimiert und es kann trotzdem mit Inversion Of Control gearbeitet werden.
Für mich gibt es aber schon noch Punkte, welche für den Einsatz in einem Produktiv-System
angeschaut werden müssen. Für mich stellt sich zum Beispiel die Frage, wie vor der Laufzeit oder
beim Start der Anwendung überprüft werden kann, ob alle Typen, welche benötigt werden, auch
registriert wurden.
Insgesamt gesehen werde ich den Service Locator beim nächsten Projekt wieder einsetzen, und
dieses Prinzip künftig weiterverfolgen.
Ablauf Trotz des relativ straffen Zeitplans konnte dieser eingehalten werden. Die genauen Stunden habe ich
leider nicht erfasst. Geschätzt würde ich sagen, dass der effektive Aufwand leicht über dem
veranschlagten war.
7.4 Schlusswort
Für mich war die Master-Thesis-Zeit sehr spannend, lehrreich, aber auch anstrengend. Durch das
Erarbeiten der verschiedenen Konzepte in der Design-Phase und durch das Implementieren des
Prototyps konnte ich sehr viel über Software-Architektur, Software-Entwicklung, WPF und .NET
dazulernen. Dabei habe ich aber auch gesehen, dass es für mich noch sehr viel zu lernen gibt. Mit den
erarbeiteten Konzepten und dem Prototyp kann ich hoffentlich der Firma Ammann Schweiz AG auf
dem Weg zur Steuerungsvisualisierung mit WPF einen kleinen Schritt weiterhelfen.
Anhang Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 52 von 59
Anhang 8
8.1 Literaturverzeichnis
Ambler, Scott W. The Agile Unified Process (AUP). [Online] Ambysoft.
http://www.ambysoft.com/unifiedprocess/agileUP.html.
Blockis, Glenn. Managed Extensibility Framework. [Online] http://msdn.microsoft.com/en-
us/magazine/ee291628.aspx.
Brumfield, Bob, et al. 2011. Developer's Guide to Microsoft® Prism 4: Building Modular MVVM
Applications with Windows Presentation Foundation and Microsoft Silverlight. s.l. : Microsoft Press
Corp., 2011. ISBN:978-0735656109.
Dino, Esposito. 2008. Microsoft® .NET: Architecting Applications for the Enterprise. s.l. : Microsoft
Press, 2008. ISBN:978-0735626096.
Fraser, Stephen. 2008. Pro Visual C++/CLI and the .NET 3.5 Platform. s.l. : Springer Verlag Gmbh,
2008. ISBN:978-1430210535.
Hall, Gary McLean. 2010. Pro WPF and Silverlight MVVM: Effective Application Development with
Model-View-Viewmodel. s.l. : Apress, 2010. ISBN:978-1430231622.
Karl Shifflett Program Manager on Patterns and Practices Team. Karl On WPF - .NET. [Online]
Microsoft Corporation. http://karlshifflett.wordpress.com/. Larman, Craig. 2001. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and
Design and the Unified Process. s.l. : Prentice Hall PTR, 2001. ISBN:978-0130925695.
MacDonald, Matthew. 2008. Pro WPF in C# 2008: Windows Presentation Foundation with .Net 3.5.
s.l. : Apress, 2008. ISBN:978-1590599556.
Martin, Hitz, et al. 2005. UML @ Work. Objektorientierte Modellierung mit UML 2. s.l. : Dpunkt
Verlag, 2005. ISBN:978-3898642613.
Melnik, Grigori. 2011. Patterns & Practices - Unity. [Online] Microsoft, 10. 05 2011.
http://unity.codeplex.com/.
Rupp, Chris. 2007. Requirements-Engineering und -Management. s.l. : Hanser Fachbuchverlag, 2007.
ISBN:978-3446405097. Wenger, Rolf. 2007. Handbuch der .NET - Programmierung: Das komplette Wissen von C# 2005 bis
zur Client/Server-Programmierung. s.l. : Microsoft Press Deutschland, 2007. ISBN:978-3866454194.
—. 2010. Handbuch der .NET 4.0-Programmierung Band 1 C# und .NET-Grundlagen. s.l. : Microsoft
Press, 2010. ISBN:978-3866454385.
—. 2011. Handbuch der .NET 4.0-Programmierung. Band 2: Benutzeroberflächen mit WPF, Windows
Forms, ASP.NET und Silverlight. s.l. : Microsoft Press, 2011. ISBN:978-3866454392 .
Anhang Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 53 von 59
8.2 Abbildungsverzeichnis
Abbildung 1 Agile Unified Process (Quelle http://www.ambysoft.com) ................................................ 2
Abbildung 2 Zerlegung des Systems ........................................................................................................ 5
Abbildung 3 Unsafe C++ Variante ............................................................................................................ 9
Abbildung 4 C# Code Behind Variante .................................................................................................. 10
Abbildung 5 WPF DataBinding (Hall, 2010) ........................................................................................... 11 Abbildung 6 MVVM ............................................................................................................................... 11
Abbildung 7 C# MVVM Variante............................................................................................................ 12
Abbildung 8 Präferenz-Matrix ............................................................................................................... 13
Abbildung 9 Nutzwert-Analyse .............................................................................................................. 14
Abbildung 10 Funktionsweise des Service-Locators ............................................................................. 17
Abbildung 11 Common Service Locator ................................................................................................ 17
Abbildung 12 Diagramm Separated Interface ....................................................................................... 18
Abbildung 13 Übersicht Architektur ...................................................................................................... 20
Abbildung 14 Klassendiagramm Automations-Element ....................................................................... 22
Abbildung 15 Add Item Template ......................................................................................................... 23 Abbildung 16 ItemTemplate AutomationElement ................................................................................ 23
Abbildung 17 MEF Export Import .......................................................................................................... 25
Abbildung 18 Aufbau Prototyp .............................................................................................................. 27
Abbildung 19 Übersichts-Diagramm Automations-Elemente darstellen .............................................. 28
Abbildung 20 Sequenzdiagramm Automation-Element darstellen ...................................................... 29
Abbildung 21 Prototyp Menu ................................................................................................................ 30
Abbildung 22 SurfaceAutomationElement Style ................................................................................... 31
Abbildung 23 Darstellung Design-Modus .............................................................................................. 32
Abbildung 24 Dialog AddSurfaceElement ............................................................................................. 33
Abbildung 25 Sequenzdiagramm Automations-Element hinzufügen ................................................... 33 Abbildung 26 Sequenzdiagramm Design-Modus .................................................................................. 34
Abbildung 27 Visual States .................................................................................................................... 34
Abbildung 28 Darstellungsvarianten umschalten ................................................................................. 35
Abbildung 29 Pcs-Nachrichten Contracts .............................................................................................. 38
Abbildung 30 Übersichts-Klassendiagramm Pcs-Nachrichten .............................................................. 39
Abbildung 31 Empfangene Pcs-Nachricht verarbeiten ......................................................................... 40
Abbildung 32 Sequenzdiagramm Pcs-Nachricht empfangen ................................................................ 41
Abbildung 33 Sequenzdiagramm Pcs-Nachricht marshalling ................................................................ 41
Abbildung 34 Sequenzdiagramm Event ausführen ............................................................................... 42
Abbildung 35 Prototyp .......................................................................................................................... 43 Abbildung 36 Sequenzdiagramm Abnahmekriterium ........................................................................... 46
Abbildung 37 WPF Performance Tool ................................................................................................... 48
Anhang Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 54 von 59
8.3 Iterations-Plan
8.3.1 Iterationsplan: Iteration 1 (1.4. – 27.4.2011)
8.3.1.1 Ziele dieser Iteration
Das Hauptziel dieser Iteration ist das Erstellen des Pflichtenheftes.
Dabei stehen natürlich auch das Einarbeiten und das Analysieren des gesamten Projektes im
Vordergrund.
8.3.1.2 Wochenplanung
Woche 1
• Einarbeiten in das Projekt. Projekt-Planung erstellen. Analyse des vorhandenen Systems.
Woche 2
Weitere Analyse und das Erstellen des Pflichtenheftes.
Woche 3
Weitere Analyse und das Erstellen des Pflichtenheftes.
Woche 4 Weitere Analyse und das Erstellen des Pflichtenheftes.
8.3.1.3 Was soll am Ende erreicht sein?
Am Ende dieser Iteration soll das Pflichtenheft fertiggestellt sein.
Anhang Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 55 von 59
8.3.2 Iterationsplan: Iteration 2 (2.5. – 29.5.2011)
8.3.2.1 Ziele dieser Iteration
• Das Hauptziel dieser Iteration ist es, die Entscheidung zu treffen, wie die Automations-
Elemente programmiert werden.
• 1. Teil Performance Tests durchführen.
• Wie können Automations-Elemente dynamisch geladen werden?
8.3.2.2 Wochenplanung
Woche 2.5. - 8.5
• Analyse der Anforderungen und Identifikation der Teilprobleme für die Lösungssuche.
• Grundlagen C++/CLI, C# MVVM erarbeiten. Dieses Wissen wird für die Erarbeitung der
Lösungsvarianten benötigt.
Woche 9.5. - 15.5.
• Grundsätzliche Lösungs-Varianten für die Erstellung der Automations-Elemente erarbeiten.
• Diplomplattform: Definitiver Projektantrag und Abstract hochladen.
Woche 16.5. - 22.5.
• Performance Tests: Anzahl Elemente / Anzahl Detailänderungen. Tool programmieren mit
welchem diese Tests durchgeführt werden können.
• Überlegungen zur groben Architektur des Prototyps.
Woche 23.5. - 29.5.
• Präferenz-Matrix für die Entscheidung, wie Automations-Elemente erstellt werden, ausfüllen.
• Entscheiden, welche Variante für das Erstellen von Automations-Elementen benutzt wird.
• Konzept erstellen, wie Automations-Elemente dynamisch geladen werden können.
8.3.2.3 Was soll am Ende erreicht sein?
Die Entscheidung, wie Automations-Elemente erstellt werden, ist anhand mehrerer Lösungsvarianten
getroffen.
In der Dokumentation ist ein Konzept beschrieben, wie die Automations-Elemente dynamisch
geladen werden können.
Es wurde mindestens ein Tool programmiert, mit welchem die Performance (Anzahl Elemente /
Anzahl Detailänderungen pro Sekunde) getestet werden kann.
Anhang Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 56 von 59
8.3.3 Iterationsplan Iteration 3 (30.5. – 26.6.)
8.3.3.1 Ziele diese Iteration
• Das Hauptthema dieser Iteration ist das Senden und Empfangen von Pcs-Nachrichten.
• Architektur des Prototypen.
8.3.3.2 Wochenplanung
Woche 1
• Konzept erstellen, wie Pcs-Nachrichten in eine .NET Applikation vermittelt werden können.
Woche 2
• Konzept erstellen, wie Automations-Elemente dargestellt werden können.
Woche 3
• Ein Tool für die Messung der Performance beim Senden von Pcs-Nachrichten erstellen.
• Konzept erstellen, wie verschiedene Darstellungsvarianten von einem Automations-Element
erstellt werden können.
Woche 4
• Konzept erstellen, wie kundenspezifische Automations-Elemente erstellt werden können.
• Konzept erstellen, wie ein Design-Modus realisiert werden kann.
8.3.3.3 Was ist am Ende erreicht?
Es ist eine Lösung erarbeitet, wie Pcs-Nachrichten in eine .NET Applikation vermittelt werden
können. Dazu ist ein Prototyp erarbeitet, um Performance Tests durchzuführen.
Die Architektur für den Prototyp ist so weit fertig, dass mit der Programmierung begonnen werden
kann.
Anhang Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 57 von 59
8.3.4 Iterationsplan Iteration 4 (27.6. – 31.7.)
8.3.4.1 Ziele diese Iteration
Hauptziel dieser Iteration ist es, einen ersten Teil des Prototyps zu implementieren. Dabei liegt der
Schwerpunkt bei den Automations-Elementen.
8.3.4.2 Wochenplanung
Woche 1
• Überlegungen zu „Dynamik der Benutzeroberfläche“
• Implementieren der Shell (Host-Anwendung), worin die Steuerungsvisualisierung dargestellt
wird.
Woche 2
• „Automations-Element erstellen“ implementieren.
• „Automations-Elemente dynamisch laden“ implementieren.
• „Automations-Element anzeigen/darstellen“ implementieren.
Woche 3
• „Automations-Element anzeigen/darstellen“ implementieren 2. Teil.
• „Design Modus – Automations-Elemente einfügen“ implementieren
• „Design Modus ein / ausschalten“ implementieren
Woche 4
• „Design-Modus – Automations-Elemente verschieben“ implementieren.
• „Darstellungs-Varianten erstellen / umschalten“ implementieren.
8.3.4.3 Was ist am Ende erreicht?
Am Ende dieser Iteration soll der Prototyp soweit implementiert sein, dass Automations-Elemente
dynamisch geladen und dargestellt werden können. Somit kann nach dieser Iteration eine Aussage getroffen werden, ob das Konzept im Zusammenhang
mit „Automation-Elementen erstellen und anzeigen“ in Ordnung ist.
Anhang Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 58 von 59
8.3.5 Iterationsplan Iteration 5 (30.7. – 28.8.)
8.3.5.1 Ziele diese Iteration
Hauptziel dieser Iteration ist es, den zweiten Teil des Prototyps zu implementieren. Dabei liegt der
Schwerpunkt bei der Vermittlung der Pcs-Nachrichten.
Weiter soll die Dokumentation auf einen „guten“ Stand gebracht werden.
8.3.5.2 Wochenplanung
Woche 1
• Urlaub
Woche 2
• Urlaub
Woche 3
• Implementation Pcs-Nachrichten senden / empfangen
Woche 4
• Implementation Pcs-Nachrichten senden / empfangen
• Dokumentation
8.3.5.3 Was ist am Ende erreicht
Am Ende dieser Iteration soll der Prototyp soweit implementiert sein, dass Pcs-Nachrichten gesendet
und empfangen werden können.
Somit kann nach dieser Iteration eine Aussage getroffen werden, ob das Konzept im Zusammenhang
mit den Pcs-Nachrichten in Ordnung ist.
Anhang Steuerungsvisualisierung mit .NET/WPF
Simon Röthlisberger Seite 59 von 59
8.3.6 Iterationsplan Iteration 6 (30.8. – 22.9.)
8.3.6.1 Ziele diese Iteration
In dieser letzten Iteration geht es darum die Master Thesis abzuschliessen und die Präsentation
vorzubereiten.
• Arbeit abschliessen.
• Abnahmekriterien prüfen
• Dokumentation abschliessen
• Präsentation vorbereiten
• Plakat erstellen