Steuerungsvisualisierung mit .NET/WPFstatic.sws.bfh.ch/download/MT-11-01-08-doc.pdf · Einleitung...

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



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)



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


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



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



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.



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



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»



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»



////////////////////////////////////////////////////////////////////////// // 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() { ; }

};


• 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»



• 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#



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


• 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»



Abbildung 8 Präferenz-Matrix



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


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(); }

} }



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.



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



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


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).



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



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.



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



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



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.



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;



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

{



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



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



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()



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



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»



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.



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



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



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



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.



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.



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.



_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



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



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)



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


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


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


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



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()



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.



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



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



1200 Stück 59 % CPU Leistung

DependencyProperty jedes Element alle 200ms eine Änderung





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




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


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


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


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 .



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



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.



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?


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.



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.


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.





Hauptziel dieser Iteration ist es, einen ersten Teil des Prototyps zu implementieren. Dabei liegt der

Schwerpunkt bei den Automations-Elementen.


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.





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.


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.





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

Date post:	17-Sep-2018
Category:	Documents
Upload:	hoangtuyen
View:	216 times
Download:	0 times

Steuerungsvisualisierung mit .NET/WPFstatic.sws.bfh.ch/download/MT-11-01-08-doc.pdf · Einleitung...

Documents