Stefan Röttger

Vergleich von Konzept und realisierten Addin

Das realisierte Addin zeigt eine gute Übereinstimmung mit dem angedachten Konzept. Die Position eines Fähnchens zeigt deutlich die Dringlichkeit und Priorität an. Die Aufgaben sind nicht mehr starr einem Quadranten zugeordnet sondern bewegen sich abhängig von der Restlaufzeit auf dem Brett. Des Weiteren hat der Anwender die Möglichkeit, einen Blick in die Zukunft und in die Vergangenheit zu werfen.

Bild: das Outlook-Addin

Einige Unterschiede zeigen sich bei der Handhabung der Priorität. In dem Outlook-Addin gibt es drei feste Prioritäten. Des Weiteren kann sich die Priorität einer Aufgabe während der Laufzeit nicht ändern. Die Gründe dafür sind vielfältig: während der Anfertigung der Bachelorarbeit wurde in der zugewiesenen Abteilung ausschließlich Outlook 2003 verwendet. In diesem Programm gibt es 5 statt 3 Prioritätsstufen. Durch eine höhere Stufenzahl lassen sich feinere Unterschiede visualisieren.
Ein weiterer Punkt war die schwindende Übersichtlichkeit durch eine Bewegung parallel zu der Vorderkante des Bretts. Die Fähnchen begannen ineinander zu wandern und sich zu überlappen. Ein Lösungsansatz für diese Unzulänglichkeit wäre ein aufwändiges Hittesting zwischen den Fähnchen gewesen. Damit steigt jedoch der Entwicklungsaufwand zusätzlich zur Steuerung einer zweiten Animation noch einmal an.
Einige weitere Ideen und Konzepte wurden zugunsten einer übersichtlichen Oberfläche nicht verwirklicht. Meist bedeuten kleine, unscheinbare Funktionalitäten einen erheblichen Programmieraufwand, ohne einen erheblichen Nutzen darzustellen. Darauf wurde verzichtet und stattdessen Entwicklungszeit in die Oberfläche des Addins gesteckt. Dadurch steht dem Anwender eine aufgeräumte Oberfläche zur Verfügung. Diese lässt sich leicht bedienen und zeigt alle wichtigen Informationen zu einer Aufgabe im Bedarfsfall an.

Persönliche Eindrücke

Insgesamt war die Projektarbeit ein interessantes Thema. Ich empfand es sehr positiv, eine moderne Programmiersprache kennen zu lernen. Ein wenig nachteilig ist das Anfertigen des Projekts als Einzelarbeit. Einige Hürden, wie die Animationen, erschienen teilweise als unüberwindbar, da eine gegenseitige Motivation fehlte.
Es ist auch interessant festzustellen, wie schnell tolle Ideen und Konzepte über Board geworfen werden, wenn es an Zeit und Lösungsansätzen bei der Programmierung mangelt. Diese Erfahrung sollte man nicht erst als arbeitender Ingenieur machen.

C#

Obwohl ich kein allzu großer Freund von Microsoft bin, hat mich C# positiv überrascht. Die Sprache lässt sich grundsätzlich programmieren wie C++, enthält jedoch viele sinnvolle Verbesserungen. Gedanken über Zeiger oder Referenzen muss man sich nicht machen. Illegales Casting in andere Datentypen oder Klassen sind kaum möglich. Vielmehr gibt es Probleme, ein Objekt einer unbekannten Klasse gezielt in eine bestimmte Klasse zu casten. Insgesamt lässt sich durch den Verzicht auf Zeigern viele Fehler vermeiden. Es gibt keine Mehrfachreferenzierungen und Daten werden nicht urplötzlich in das Nirvana des RAMs geschrieben.
Viele, sehr interessante Feinheiten von C# lernte ich jedoch erst sehr spät kennen oder wurde zufällig bei der Suche nach anderen Problemen darauf aufmerksam gemacht. Dazu gehört der as-Operator. Mit ihm kann man auf Klassen casten, ohne eine Exception im Fehlerfall zu erzeugen.
Ein wenig merkwürdig dagegen ist die Handhabung von Konstanten und Structs. Konstanten lassen sich nicht wie in C++ als #define festlegen. Stattdessen werden die Konstanten in static-Klassen abgelegt. Allerdings muss man dies als Umsteiger erst einmal wissen.
Structs sind auf dem ersten Blick Klassen mit einem anderen Namen und public Member-Variablen. Für eine Zuweisung von Daten während der Deklaration einer Struct wird sogar ein Konstruktor in der Struct benötigt. Des Weiteren können, ähnlich wie in einer Klasse, auch Methoden in die Struct einprogrammiert werden.
Eine für mich sehr interessante Feststellung ist die Kompaktheit des Codes. In Verbindung mit .NET sind viele Probleme in wenigen Zeilen ( < 10) lösbar. Aufgrund von neuen Operatoren und des Umfangs von .NET ist jedoch teilweise mehr Denkaufwand nötig, diese Zeilen nach und nach auszuarbeiten.

.NET

Das .NET-Framework ist für den Software-Entwickler im Vergleich zu der Standard C API um ein Vielfaches hilfreicher. Beispielsweise ist die Handhabung der Zeitspannen für die Animationen sehr einfach gemacht. Statt eine eigene Zeit-Klasse dafür zu schnitzen, wird sie fertig aus dem Framework benutzt.
Auch die 3D-Objekte sind gut verwendbar. An jedes 3D-Objekt lässt sich eine Transformation anhängen.
Einige Konzepte in .NET sind sinnvoll durchdacht, jedoch nicht intuitiv und nirgends beschrieben. Dazu gehören beispielsweise die Animationen. Die Verwendung der AnimationClock ist einfach und sinnvoll gestaltet. Allerdings empfand ich es äußerst merkwürdig, die AnimationClock von einer Animation ableiten zu müssen.
Für mich kaum nachvollziehbar war die Handhabung von Klassen mit Referenzen auf “Kind”-Objekte. Ein Beispiel dafür ist die ModelGroup3D: man fügt mehrere 3D-Figuren als Children einer ModelGroup3D ein. Ein nachträgliches Auslesen der Children versuchte ich mehrfach vergebens.

Oberflächen mit WPF

Bei der Erstellung einer einfachen Oberfläche will man die einzelnen Schaltflächen irgendwie im Programmfenster verteilen und nicht weiter darüber nachdenken. Diese Vorgehensweise funktioniert zwar auf dem ersten Blick mit WPF. Beim Vergrößern des Programmfensters zeigen sich jedoch Schwächen in der Oberfläche: plötzlich werden Bildlaufleisten auseinandergezogen, Buttons entfernen sich voneinander.
Bei einer überlegten Rangehensweise stößt man jedoch auf sinnvolle Lösungsansätze von WPF. Mit Hilfe von DockPanels lassen sich Frames in dem Programmfenster erstellen. StackPanels verhindern das Umherfliegen von Buttons und richten ähnliche Steuerelemte ganz allein aus. Viele User bemängeln zwar die Benutzbarkeit des Oberflächeneditors von Visual Studio, ich konnte jedoch keine großen Schwächen feststellen.

3D-Darstellungen mit WPF

WPF bietet an sich ein umfangreiches Paket für 3D-Objekte. Allerdings wird das händische Schnitzen von Objekten sehr schnell nervenaufreibend und man möchte lieber auf eine Modellierungssoftware zurückgreifen.
Das “Verpacken” von einzelnen 3D-Objekten vom einfachen Polygon bis hin zu einer komplexen dreidimensionalen Figur erscheint anfangs merkwürdig. Von einer MeshGeometry3D zu einem Model geht es über ModelGroup3D-Objekte weiter zu ModelVisual3Ds, die ebenfalls wieder gruppiert werden können.
Eine ausgeprägte Belastung des Systems durch WPF, wie mir Einige beschrieben, konnte ich nicht feststellen. Leider sind viele Einstellungsmöglichkeiten zu Antialiasing oder Filterung nur rudimentär vorhanden. Eine Optimierung des Rechenaufwandes an die vorhandene Hardware ist damit schwer möglich. Komplexere 3D-Anwendungen würden somit auf älteren Systemen kaum benutzbar sein.
Erste Stimmen sagen bereits heute schon den Untergang von WPF voraus. Während dieser Projektarbeit wurde WebGL veröffentlicht, dass bereits als interessanter Nachfolger von WPF gehandelt wird. An dieser Stelle soll nicht weiter darüber spekuliert werden. Klarer Vorteil wäre jedoch die Verwendung von Standards für die 3D-Programmierung.

← Benutzerdefinierte Animationen mit WPF | ● | Literatur →